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Preface 


Moving  to  a  Product  Line  Approach 

When  an  organization  makes  the  decision  to  move  to  a  product  line’  approach  for  acquiring 
or  developing  software,  it  must  address  several  key  issues: 

1.  What  constitutes  the  product  line? 

2.  How  will  the  product  line  be  introduced? 

3.  What  are  the  key  organizational  elements  involved  in  defining,  developing,  and  fielding 
the  product  line? 

4.  What  is  the  relationship  between  the  product  line  assets  and  systems  within  the  product 
line? 

5.  How  will  the  architecture  be  developed  and  maintained? 

6.  What  are  the  sources  of  software  components  and  other  assets? 

The  decisions  regarding  these  and  several  other  key  questions  establish  the  basis  for  a 
product  line.  As  these  decisions  become  operational,  the  organization  establishes  a  process 
for  fielding  the  product  line.  The  definition,  development,  and  maintenance  of  this  process 
require  an  operational  concept  in  order  to 

1 .  describe  the  characteristics  of  the  process  for  fielding  the  product  line  from  an 
operational  perspective.  (Included  in  fielding  are  product  line  development  or 
acquisition  and  product  line  sustainment  throughout  its  life.) 

2.  facilitate  understanding  among  stakeholders  of  the  goals  of  this  process.  Stakeholders 
for  the  product  line  include  developers  and  users  of  the  products  of  the  process. 

3.  form  an  overall  basis  for  long-term  planning  for  the  product  line  and  provide  guidance 
for  the  development  of  specific  product  line  outputs  such  as  a  Developers’  Guide, 
Business  Plan,  Architecture,  and  other  assets. 

4.  describe  the  organization  fielding  the  product  line  and  using  product  line  products. 

5.  define  the  role  acquisition  will  play  and  solidify  the  general  acquisition  approach. 
Acquisition  will  include  procurement  strategies  for  asset  development,  product 
development,  and/or  needed  contractual  products  and  services. 

As  the  product  line  is  fielded,  the  operational  concept  provides  a  baseline  when  the 
organization  considers  alternatives  in  its  approach  as  changing  conditions  warrant. 

*  Detailed  information  about  product  lines  and  related  technology  can  be  found  in  the  Product  Line 
Framework  [Clements  99]. 

^  Based  on:  “Guide  for  the  Preparation  of  Operational  Concept  Documents”  ANSI/AIAA  G-043- 
1992  [AIAA93]. 
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The  Concept  of  Operations 

The  operational  concept  for  a  product  line  should  be  documented  as  a  Concept  of  Operations 
(CONOPS).  It  is  generally  the  purpose  of  a  CONOPS  to  represent  the  systems  user's 
operational  view  for  a  system  under  development.  This  operational  view  is  stated  in  terms  of 
how  a  system  will  operate  in  its  intended  environment.  In  the  case  of  fielding  a  product  line, 
we  are  discussing  a  process  rather  than  a  system;  the  users  of  that  process  include  a  wide 
range  of  stakeholders  for  the  product  line.  The  CONOPS  for  that  process  will  accomplish 
much  the  same  purpose  as  a  CONOPS  for  a  system  by  describing  how  the  mission  or  purpose 
of  the  product  line  will  be  fulfilled,  the  environment  for  fielding  the  product  line,  and  the 
organizational  structure  for  its  fielding.  Specifically,  the  CONOPS  for  a  product  line  will 
contain  the  following: 

1.  how  -  the  strategies,  tactics,  policies,  and  constraints  that  describe  how  the  product  linp; 
process  will  be  used  to  field  the  product  line 

2.  who  does  what  -  the  organizations,  activities,  and  interactions  that  describe  who  will 
participate  in  fielding  the  product  line  and  what  these  stakeholders  do  in  that  process 

3.  when  -  the  specific  operational  processes,  in  overview  fashion,  that  provide  a  process 
model  for  fielding  the  product  line  in  terms  of  when  and  in  what  order  these  operational 
processes  take  place,  including  such  things  as  dependencies  and  concurrencies 

Role  of  Development  and  Acquistion 

This  report  provides  guidelines  and  examples  for  a  variety  of  development  or  acquisition 
approaches.  The  report  is  intended  for  government  organizations,  government  contractors, 
and  commercial  organizations.  Software  assets  for  a  product  line  enter  these  organizations 
through  one  of  three  ways:  the  organization  develops  it  (builds  it  itself,  either  from  scratch  or 
by  mining  legacy  software),  purchases  it  (buys  it,  largely  unchanged,  off  the  shelf)  or 
commissions  it  (contracts  with  someone  else  to  develop  it  especially  for  them).  The 
organization  may  use  its  assets  in  house  for  product  development  or  may  again  commission 
someone  else  to  use  the  assets  for  development  of  products.  Government  acquisition  of 
product  lines  is  most  often  achieved  by  commissioning  both  asset  and  product  development, 
although  some  government  organizations  maintain  in-house  development  groups. 

The  CONOPS  should  spell  out  the  specific  product  development  strategies  and  the  role 
development  or  acquisition  will  play  in  fielding  the  product  line.  These  development  and 
acquisition  approaches  may  involve  a  combination  of  government,  government  contractors  or 
purely  commercial  activities  operating  under  widely  different  circumstances: 

1 .  A  government  organization  may  acquire  software  systems  as  part  of  a  product  line. 
Several  alternatives  exist  for  this  acquistion  process,  including:  commisioning  all  product 
line  development,  in-house  scoping  of  the  product  line  and  development  of  an 
architecture,  contractor  development  of  the  architecture,  or  contractor  development  of 
products  from  government  assets. 

2.  A  commercial  organization  develops  its  own  architecture,  con^onents,  and  other  assets. 
These  are  used  to  provide  individual  products  in  the  product  line  internally  or  to  external 
customers.  A  government  contractor  may  elect  to  develop  assets  in  anticipation  of  future 


viii 
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contract  work.  An  alternative  may  see  a  commercial  organization  contracting,  like  the 
government,  for  product  line  assets. 

The  guidelines  in  this  report  do  not  illustrate  every  possible  combination  and  alternative  that 
could  be  covered  by  a  CONOPS,  but  do  indicate  where  the  alternatives  will  affect  decision 
making.  An  organization  develops  its  CONOPS  to  establish  the  desired  product  line  approach 
that  it  wishes  to  take.  These  guidelines  recommend  a  detailed  description  of  the  selected 
approach  and  possible  presentation  of  alternatives.  The  resulting  CONOPS  documents  the 
decisions  that  define  the  approach  and  the  organizational  structure  needed  to  put  the  approach 
into  operation. 

Using  the  CONOPS 

The  CONOPS  should  relate  a  narrative  of  the  process  to  be  followed  in  fielding  the  product 
line.  It  must  also  speak  to  the  various  product  line  stakeholders.  The  CONOPS  addresses 
these  needs  through  describing  the  process  and  organization  for  fielding  a  product  line  and 
also  listing  key  action  steps  for  putting  the  CONOPS  into  effect.  While  the  CONOPS  does 
not  provide  a  complete  process  model,  it  does  provide  sufficient  detail  to  help  relate  core 
assets  and  system  products  to  the  development  organizations  producing  or  using  them. 

The  guidelines  are  not,  however,  intended  to  support  an  implementation  or  transition  plan 
since  they  do  not  provide  managers  with  the  detailed  steps  involved  in  planning  for  the 
transition — ^for  example,  establishing  accountability,  managing  risk,  scheduling,  and 
budgeting.  The  guidelines  do  offer  a  clear  set  of  steps  to  realize  the  goals  and  objectives  of 
the  product  line  approach  to  software  development/acquisition  of  core  assets  and  of  systems 
within  the  product  line. 

A  CONOPS  should  address  a  number  of  key  product  line  issues  both  for  core  asset  and 
product  development.  An  oiganization  needs  to  address  these  issues  as  it  makes  product  line 
decisions.  For  product  development,  the  guidelines  will  help  address  the  needs  of  program 
managers,  developers  and  others  in  a  product  oversight  or  decision-making  role.  The 
guidelines  also  apply  to  the  needs  of  future  reusers  of  product  line  assets  who  will  be  building 
derivative  systems.  The  issues  may  be  grouped  into  categories  as  shown  in  the  following 
table. 
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ix 


Categories 

Core  Asset  Development 

Product  Development 

Key  decisions 

Process  and  organization  for 
developing  core  assets;  key 
action  steps  for  putting  the 
CONOPS  into  effect 

Process  and  organization  for 
developing  products  in  the 
product  line 

Components 

Known  components  or  elements 
in  the  product  line  including  the 
product  line  scope,  the 
architecture  and  other  assets,  and 
the  product  line  activities 

Effects  of  using  product  line 
assets  in  developing  products 

Context 

Relationships  among  the 
stakeholders  and  sources  for 
asset  development:  legacy 
systems  and  assets,  asset 
developers  and  product  users 

Relationships  among  the 
stakeholders  and  assets  for 
product  development:  product 
line  assets,  asset  developers, 
product  developers  and  product 
users 

Activities 

Sequence  of  activities  moving 
from  product  line  scoping, 
through  architecture,  and 
component  development. 

Product  line  sustainment 

Activities  for  using  cote  assets  in 
the  development  of  individual 
products 

Organizational 

elements 

Organizational  elements  and  the 
role  they  play  in  fielding  the 
product  line 

Organizational  elements  and  the 
role  they  play  in  (he  development 
of  product  line  products 

Rationale 

Rationale  for  moving  to  a 
product  line  approach  as  well  as 
risks 

Rationale  for  using  product  line 
assets  as  bases  for  product 
development 

Integration 

Tie  together  the  above  elements 
to  provide  guidance  in 
development  activities  such  as 
the  development  of  component 
assets  and  the  use  of  the 
architecture  and  assets  in 
producing  products 

Production  plan  for  products  in 
the  product  line.  Guidance  is 
especially  important  for 
reflecting  the  results  of  using 
core  assets  in  product 
developments  to  support  their 
continued  improvement 

Table  1.  Product  Line  Issues  Addressed  by  the  CONORS 


The  guidelines  recommend  that  a  CONOPS  should  provide  a  forum  for  exchange  of 
information  on  major  technical  and  programmatic  issues  among  the  stakeholders.  This  will 
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result  in  a  common  understanding  of  the  goals  for  the  product  line,  the  structure  of  the 
product  line  organization  and  the  steps  to  be  taken  in  fielding  the  product  line. 


Using  This  Report 

This  report  serves  a  dual  responsibility  with  regard  to  supporting  an  organization  that  has 
decided  to  field  a  product  line: 

1 .  The  report  provides  a  standard  outline  and  describes  the  class  of  information  to  be 
contained  in  each  section  of  a  CONOPS  for  a  product  line. 

2.  The  document  provides  examples  from  CONOPS  adapted  for  presentation  in  the 
guidelines. 

Having  decided  to  field  a  product  line,  the  organization  should  use  the  guidelines  and 
examples  from  this  report  as  a  starting  point  for  crafting  its  own  CONOPS.  The  user  of  this 
document  should  follow  the  guidance  in  each  section  to  generate  specific  sections  of  the 
CONOPS.  Wrth  that  approach  in  mind,  each  chapter  of  this  report  is  organized  as  follows: 
overview  of  subsections,  followed  by  guidance  to  generate  each  subsection  of  the  CONOPS, 
supplemented  by  examples. 

Some  organizations  may  feel  that  the  term  “Concept  of  Operations”  should  apply  only  to 
system  developments.  In  that  case,  they  may  wish  to  use  the  title  “Product  Line  Approach.” 
We  prefer  to  apply  the  term  CONOPS  because  it  conveys  the  operational  nature  of  the 
process  for  fielding  a  product  line.  Organizations  need  not  stick  rigidly  to  the  structure 
provided  here.  This  report  should  serve  to  guide  the  development  of  the  organization’s 
operational  concept.  If  information  contained  here  is  not  required,  it  should  be  omitted  or 
other  information  should  be  substituted. 

The  guidelines  in  this  report  are  based  on  several  CONOPS  developed  over  a  period  of  three 
years  for  organizations  working  to  field  product  lines.  During  that  time,  the  CONOPS  has 
gone  through  several  rounds  of  reviews,  changes,  and  major  revisions.  The  guidelines  have 
been  distilled  to  a  form  suitable  for  use  by  government,  government  contractors,  and 
commercial  industry.  In  using  this  report,  you  will  no  doubt  find  areas  that  proved  helpful  or 
that  were  difficult  to  apply.  Your  comments  are  appreciated  and  will  be  useful  in  improving 
the  quality  and  applicability  of  the  guidelines  for  other  users. 

An  excellent  set  of  reviewers  made  possible  the  production  of  the  Guidelines.  I  would  like  to 
acknowledge  the  contributions  of  Matt  Fisher,  Nelson  Weiderman,  John  Bergey,  Linda 
Northrop,  and  Paul  Clements  who  provided  thoughtful  and  extensive  reviews. 

Sholom  Cohen 
May  1999 
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Abstract 


This  report  provides  guidelines  for  an  organization  that  is  developing  a  Concept  of 
Operations  (CONOPS)  document.  A  CONOPS  document  defines  the  organization’s  product 
line  approach.  The  CONOPS  document  and  the  decisions  made  in  its  preparation  will  guide 
the  organization  as  it  plans  and  executes  the  process  of  fielding  a  prodttbt  line,  from  product 
line  scoping,  through  architecture,  component  development,  and  product  development. 

Organization  of  This  Report 

The  chapters  of  this  report  represent  a  tenqrlate  for  the  chapters  of  an  actual  CONOPS.  For 
preparing  a  CONOPS,  this  report  presents  chapter-by-chapter  guidelines  and  practical 
examples  of  their  application.  Each  section  of  the  report  also  presents  a  key  set  of  decisions 
that  the  organization  must  make  to  complete  the  contents  of  that  chapter  and  action  steps  to 
bring  those  decisions  into  operation.  The  report  is  organized  into  chapters  to  present 
guidelines  in  each  of  the  following  areas: 


1 

Overview 

Product  line  concepts  and  guidelines  for  describing  the  product 
line 

2 

Approach 

Guidelines  for  describing  the  approach  for  fielding  products  in 
the  product  line 

3 

Product  line  background 

Outline  for  presenting  information  on  existing  systems  or  other 
motivation  for  the  product  line 

1 

Organizational 

considerations 

Guidelines  for  establishing  the  product  line  approach  and 
management  structure 

5 

Technical  considerations 

Guidelines  for  establishing  process  steps,  methods,  and  assets 
including  architecture 

6 

Recommendations 

Guidelines  for  setting  up  initial  organizations  and  assigning 
responsibilities 

Appendix  A 

Key  questions  to  be  answered 

Table  2.  Contents  of  a  CONOPS  Report 
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Chapter  7,  Summary,  provides  the  reader  with  a  summary  of  this  guidelines  report  and  would 

not  be  a  part  of  a  typical  CONOPS. 

This  document  uses  two  examples  for  illustrating  CONOPS  sections: 

•  ACMYWorks  represents  a  set  of  assets  for  the  pager  market.  The  developer  of 
ACMYWorks,  ACMY  Corporation,  has  a  legacy  of  pager  systems,  but  is  losing  market 
share  to  off-shore  sources.  To  capitalize  on  their  experience,  they  are  developing 
ACMYWorks  as  a  set  of  assets  for  the  high-end  pager  product  line.  ACMYWorks  will  be 
used  in  ACMY’s  new  products  and  will  be  sold  as  a  product  line  support  asset  base  for 
other  pager  developers. 

•  Battlefield2000  is  a  set  of  assets  to  support  systems  for  battlefield  command  and  control 
missions.  The  assets  were  commissioned  by  a  DoD  organization.  The  DoD  will  foster 
their  use  in  new  battlefield  C2  systems  that  will  be  contracted  to  the  Battlefield2000 
developer  and  to  other  DoD  contractors. 

In  addition  to  examples,  the  guidelines  include  the  following: 

•  specific  product  line  issues  that  an  organization  should  address 

•  recommended  actions  that  the  organziation  should  take 

in  fielding  a  product  line.  Issues  appear  near  the  beginning  of  sections  or  subsections  where 

they  should  be  addressed.  Actions  appear  at  the  end  of  sections  and  subsections. 
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1  Creating  the  CONOPS  Overview  Chapter 


The  overview  section  of  the  concept  of  operations  (CONOPS)  should  identify  the  product 
line  and  its  context.  It  must  establish  the  purpose  of  the  CONOPS  document,  provide  basic 
product  line  concepts,  and  explain  to  readers  why  the  organization  is  adopting  a  product  line 
approach.  This  section  should  also  establish  the  readership  for  the  CONOPS  and  describe  the 
content  of  each  section. 


The  CONOPS  Overview  chapter  is  organized  into  the  following  sections: 


Identification 

Identifies  the  product  line  and  its  context 

Concepts 

Provides  some  basic  definitions  of  concepts  behind  the 
approach 

Product  line  variation 

Discusses  parameters  of  the  product  line  development  (how 
development  is  accomplished,  shared  responsibilities,  nature 
of  product  line,  greenfieldMegacy,  etc.) 

Readership 

Explains  the  message  the  CONOPS  delivers  to  each 
stakeholder  and  provides  an  overview  of  contents 

A  product  line  approach  for  product  development  usually  represents  a  major  change  in  an 
organization's  way  of  doing  business.  An  organization  produces  CONOPS  document  to 
describe  how  a  product  line  approach  will  operate  within  the  otganization.  A  broad  set  of 
product  line  issues  must  be  discussed  and  resolved  by  a  wide  range  of  stakeholders.  The 
audience  for  the  CONOPS  includes  the  following  product  line  stakeholders:  asset  developers, 
product  developers,  management  at  various  levels,  product  users  or  their  representatives,  and 
support  organizations.  The  topics  covered  in  a  CONOPS  arise  from  various  decisions  made 
by  the  stakeholders  about  the  product  line.  These  decisions  include 

•  product  line  scope 

•  development  processes 

•  assets  to  be  developed 


^  A  greenfield  effort  is  a  development  not  constrained  by  prior  systems.  The  name  is  derived  from 
major  construction  efforts.  For  example,  the  Denver  hiteroational  Airport  was  a  greenfield  effort; 
the  new  Reagan-National  Airport  was  constrained  by  existing  terminals,  runways,  rivers,  highways, 
etc. 
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•  architecture  for  the  product  line 

•  production  plan  for  product  line  products 

•  role  development/acquisition  will  play 

•  plan  for  introducing  the  product  line 

This  is  not  meant  to  be  an  exhaustive  list,  nor  are  these  decisions  independent  of  each  other. 
There  is  significant  overlap.  Ideally,  the  CONOPS  should  provide  a  narrative  that  describes 
how  the  product  line  approach  will  be  introduced,  who  will  be  responsible  for  its 
introduction,  and  what  methods  will  be  applied. 

1 .1  Guidelines  for  Defining  the  Product  Line  and  its 
Context 


A  key  decision  to  be  made  by  the  organization  is  the  following: 

Issue  #7.  What  is  the  product  line?  What  mission  or  application  area  will  be 
satisfied  by  systems  in  the  product  line? 

The  CONOPS  should  capture  this  decision  by  both  identifying  the  product  line  and  deHning 
the  class  of  systems  for  which  it  will  apply.  For  example,  an  organization  may  be  developing 
an  asset  base  to  support  products  in  the  pager  market.  In  that  case,  the  product  line  and 
product  line  CONOPS  should  be  described  as  follows; 

ACMYWorks  is  a  collection  of  assets  that  will  support  a  product  line  of  pager 
products.  The  ACMYWorks  CONOPS  presents  a  cooperative  methodology  for 
developing  ACMYWorks  and  using  its  assets  to  produce  systems.  The  reader  is 
introduced  to  the  ACMYWorks  organization  and  processes.  A  rationale  for  the 
change  from  historical  practice  leads  to  a  convincing  argument  on  the  need  for 
shifting  to  a  concept  of  operations  based  on  a  product  line  approach  for 
development  of  new  pager  systems. 

User  involvement  is  a  key  element  of  fielding  the  product  line  and  ACMYWorks 
assets.  With  this  in  mind,  the  CONOPS  addresses  the  following  topics ....  An 
analysis  of  the  advantages  and  challenges  of  the  new  approach  and  some 
implementation  issues  are  also  presented. 

A  decision  parallel  to  that  of  product  line  description  involves  the  approach  for  developing  or 
acquiring  a  product  line: 

Issue  #2.  How  will  product  line  assets  and  product  line  products  be  developed  or 
acquired?  Is  there  an  acquisition/supplier  relationship? 
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An  organization  may  choose  one  of  several  paths  in  addressing  this  issue  and  may  even  have 
a  hybrid  approach.  The  paths  include  the  following: 

•  developing  assets  and  products  in  house 

•  commissioning  the  development  of  assets  or  products 

•  purchasing  assets  off  the  shelf  for  building  products  in  house 

The  CONORS  should  clearly  state  the  approach  the  organization  will  take.  A  pure 
development  approach  may  be  described  as  follows: 

The  ACMY  asset  development  group  will  specify  and  develop  ACMYWorks.  The 
pager  product  group  will  build  new  pager  systems  using  those  assets. 

Another  organization  may  decide  that  internal  development  costs  are  too  high  and  may  out¬ 
source  much  of  the  asset  development: 

This  CONOPS  describes  the  approach  ACMY  will  take  for  working  with 
vendor(s)  who  will  build  ACMYWorks  to  our  specification.  Product  developers 
internal  to  ACMY  will  use  ACMYWorks  to  field  our  line  of  pager  products. 

A  government  organization  without  in-house  development  staff  may  acquire  through 
contractors  both  the  assets  and  products  for  the  product  line.  In  this  case,  the  CONOPS  will 
describe  the  organizational  responsibilities  for  both  government  and  its  contractors  in 
developing  assets  and  using  assets  for  individual  products.  For  example: 

The  Battlefield2000  assets  will  be  developed  by  our  prime  contractor.  The 
Battlefield2000  contractor  along  with  other  qualified  contractors  will  use  those 
assets  in  the  development  of  battlefield  command  and  control  systems. 

A  hybrid  approach  could,  for  example,  provide  for  in-house  development  of  certain  key 
assets  (e.g.,  domain  models,  architectures,  and  foundation  frameworks),  with  other  assets  and 
product  development  out-sourced  to  contractors.  In  all  cases,  these  decisions  should  be 
clearly  defined  in  the  opening  section  of  the  CONOPS.  The  remainder  of  the  CONOPS 
document  provides  the  details  of  the  approach. 

1 .2  Guidelines  for  Introducting  Product  Line 
Concepts 

This  section  of  the  CONOPS  should  present  basic  product  line  concepts.  For  many 
stakeholders,  the  CONOPS  will  be  the  first  exposure  to  the  product  line  approach.  For  this 
reason,  the  CONOPS  must  provide  some  basic  definitions  of  concepts  behind  the  approach. 
Basic  terminology,  drawn  from  A  Framework  for  Software  Product  Line  Practice  [Clements 
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99],  will  support  this  section.  The  organization  will  add  detail  pertaining  to  their  approach. 
Key  terms  might  include  the  following: 

Product  line  -  A  software  product  line  is  a  set  of  software-intensive  systems 
sharing  a  common,  managed  set  of  features  that  satisfy  the  specific  needs  of  a 
particular  market  segment  or  mission.  A  new  pager  product  will  be  produced  by 
taking  applicable  components  from  ACMYWorks,  tailoring  them  as  necessary 
through  pre-planned  variation  mechanisms  such  as  parameterization,  adding 
any  new  components  (e.g.,  pager-unique  software  developed  by  the  ACMY 
product  groups)  that  may  be  necessary,  and  assembling  the  collection  under  the 
umbrella  of  the  ACMYWorks  product  line-wide  architecture.  Building  a  new 
pager  product  becomes  more  a  matter  of  generation  than  creation;  the 
predominant  activity  is  integration  rather  than  programming. 

Commonality/variability  (also  called  domain  engineering)  -  Asset  development 
for  a  product  line  can  be  characterized  by  capturing  the  commonalities  among 
its  members  and  by  factoring  the  ways  in  which  members  vary  from  each  other. 
ACMYWorks  features  certain  functions  common  to  all  planned  pager  systems. 

But  each  of  these  pagers  is  different  from  the  rest,  featuring  certain  capabilities 
and  satisfying  requirements  unique  to  it. 

Product  development  (also  called  application  engineering)  -  Pager  products  can 
be  most  efficiently  produced  by  taking  advantage  of  the  commonalities,  while 
planning  for  the  variations.  ACMYWorks  will  provide  a  platform  of  core  assets 
that  (a)  largely  implements  the  functionality  common  across  the  product  line; 
and  (b)  can  be  easily  tailored  to  account  for  the  variability  when  building  an 
individual  system.  Producing  any  single  member  cf  the  product  line  is  much  less 
expensive  than  if  it  were  built  entirely  from  scratch. 

1 .3  Guidelines  for  Characterizing  the  Product  Line 

This  section  of  the  CONOPS  helps  characterize  a  specific  product  line  along  a  set  of  product 
line  dimensions.  The  product  line  approach  taken  by  one  organization  and  described  in  its 
CONOPS  will  vary  from  the  approach  of  other  organizations.  This  significant  level  of 
variation  results  from  the  way  product  lines  are  defined  and  developed.  These  forms  of 
variation  may  be  placed  into  the  following  categories: 
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Variation 

Dimensions 

Product  line  attributes 

Size,  maturity,  mission/market  coverage 

Asset  procurement  approach 

Develop  in-house,  commission,  acquire  off  shelf 

Asset  categories 

Analysis  models,  architecture,  components,  others 
listed  in  Section  5.1.3 

Asset  development  approach 

Greenfield,  legacy,  evolutionary 

Use  of  assets  in  application  engineering 

Complete/partial  system,  frequency  of  use  in  product 
development,  longevity  of  product  line 

Control  over  assets 

Used  internally,  internal  and  external  use,  made 
available  for  external  use 

Table  3.  Variations  to  Consider  in  Formuiating  the  CONORS 


This  section  of  the  CONOPS  will  describe  the  product  line  according  to  these  dimensions. 
For  example: 

ACMY  corporation  has  long  been  a  leader  in  the  pager  market.  However,  off¬ 
shore  competition  has  made  it  impossible  for  us  to  maintain  our  market  share  in 
the  low-end  pager  segment.  To  address  our  possible  loss  of  market  share,  we 
will  provide  a  product  line  built  onACMYWorks  that  can  compete  in  the  high- 
level,  feature-rich,  two-way  pager  market.  We  will  also  offer  ACMYWorks  as  a 
stand-alone  software  product  for  use  by  other  pager  manufactures  in 
development  of  their  pagers.  To  support  external  use  of  ACMYWorks,  we  will 
develop  support  tools  that  allow  for  effective  black-box  application  of 
ACMYWorks  in  pager  products. 

This  example  describes  the  product  line  along  most  of  the  dimensions.  These  product  line 
variations  will  also  affect  the  content  of  the  technical  considerations  chapter  of  a  CONOPS. 
Chapter  4  of  this  report  will  provide  guidelines  for  how  specific  parameters  should  be 
accounted  for  in  the  CONOPS.  The  following  paragraphs  discuss  these  variations. 

Some  of  the  parameters  for  variation  are  really  attributes  of  the  product  line:  size  of  t3rpical 
systems,  market  or  mission  area,  level  of  maturity.  ITie  CONOPS  should  describe  the 
product  line  along  these  dimensions.  They  will  account  for  different  approaches  in  fielding  a 
product  line  that  are  documented  in  the  CONOPS. 

Other  types  of  variation  are  derived  from  the  product  line  approach:  how  assets  will  be 
acquired.  Section  1.1  of  this  report  described  the  approaches  for  developing,  commissioning 
and  buying  a  product  line  capability.  Different  assets  may  be  acquired  along  different  paths. 
There  are,  then,  hybrid  approaches  that  cross  the  boundaries  according  to  asset  type.  Table  4 
shows  variation  along  two  dimensions,  approach,  and  asset  type. 
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"■^.^pproach 

Assets 

Develop 

Commission 

Acquire  Off-the- 
Shelf 

Analysis  models 

Organization 
develops  its  own 
domain  model  or 
requirements 
database 

Organization 
contracts  for 
development  of 
models 

An  authoritative 
model  or  asset  base 
exists  for  direct 
purchase 

Architecture 
(structure  of  system, 
components, 
externally  visible 
properties  of 
components,  and 
relationships  among 
them  [Bass  98] 

In-house 

development  based 
on  own  models 

Organization 
provides  analysis 
models  to  contractor 
for  architecture 
development 

Organization  may 
acquire  architecture 
developed  externally. 
For  example, 
architectures  from  a 
standards  group 

Components 

Organization 
develops  in-house. 
May  use  architecture 
developed  in-house 
or  from  other  source 

Organization 
provides  architecture 
to  contractor  for 
development  of 
components 

Organization 

identifies 

components  that  are 
suitable  for  use  in 
own  architecture 

Table  4.  Variations  in  Developing/Acquiring  Product  Line  Assets 


Another  set  of  issues  relates  to  the  starting  point  for  development  of  assets: 

•  Greenfield  -  the  product  line  is  a  new  start.  The  technology  or  product  set  may  be  so 
new  that  no  legacy  systems  cover  the  desired  capabilities,  or  the  technology  may  drive  to 
a  new  architectural  approach  that  invalidates  much  of  the  legacy. 

•  Legacy  -  the  product  line  may  be  largely  derived  from  existing  systems.  Important  assets 
such  as  the  architecture  or  large-grained  components  may  be  avs^able  as  assets  from 
legacy.  Alternatively,  it  may  be  necessary  to  provide  an  architecture  that  can  easily 
accommodate  legacy  software  as  large-grained  con^onents. 

bi  addition,  product  line  development  may  follow  alternative  approaches  for  delivery  of 
assets  and  products: 

•  A  priori  development  -  assets  are  developed  for  subsequent  product  development. 

Limited  proof-of-concept  product  development  may  occur  in  parallel  with  asset 
development. 

•  Evolutionary  -  the  product  line  will  be  developed  incrementally  through  progressive 
refinements.  Starting  from  a  limited  capability,  the  product  line  approach  will  gftnftralizp. 
assets  for  future  product  line  application. 

V^^thin  each  area  of  Table  4  it  is  possible  to  take  one  or  more  of  these  approaches.  For 
exanq)le,  some  components  may  be  developed  from  scratch  without  regards  to  existising 
legacy  while  other  components  may  be  mined  from  existing  systems.  Also,  the  analysis 
models  may  be  completed  in  increments,  starting  with  a  core  of  critical  domains  within  the 
product  line,  providing  architecture  and  components  for  that  core,  and  continuing  the 
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evolution  to  encompass  the  entire  product  line.  Naturally,  there  is  overlap  in  these 
approaches  and  interfaces  that  are  not  strictly  defined. 

Variation  is  also  dependent  on  the  way  in  which  assets  will  be  used  in  application 
engineering.  Assets  may  be  used  to  perform  the  following: 

•  Develop  complete  systems. 

•  Use  the  architecture  as  a  basis  for  product  development  with  limited  coverage  by 
component  assets. 

•  Use  architecture  and  components  for  only  a  portion  of  the  system. 

Assets  may  be  used  in  only  a  small  number  of  products  or  in  numerous  systems.  The 
longevity  of  the  product  line  will  also  affect  the  way  the  assets  may  be  used.  The  CONOPS 
should  characterize  these  dimensions  as  well.  They  will  affect  the  production  plan  for 
systems,  and  the  extent  of  custom  software.  A  generative'*  approach  may  be  preferred  over 
composition^  if  asset  use  will  be  frequent  and  can  be  effectively  automated.  If  the  product 
line  is  expected  to  live  for  some  years,  building  a  generative  capability  may  also  be 
considered. 

The  organization  must  make  decisions  about  its  development  approach  based  on  its  plan  for 
fielding  the  product  line.  For  example,  an  organization  that  commissions  development  of 
product  line  assets  may  similarly  propose  their  use  in  commissioning  specific  products.  In 
this  case,  the  CONOPS  should  describe  how  the  organization  plans  to  commission  products 
using  these  assets.  For  example: 

Proposals  for  new  battlefield  command  and  control  systems  must  describe  the 
use  ofBattlefield2000  assets  in  fielding  these  systems.  The  program  office  will 
make  these  assets  and  details  of  prior  use  in  the  system  proposal  library. 

1 .4  Guidelines  for  Describing  Readership  for  the 
CONOPS 


The  audience  for  the  CONOPS  document  includes  a  diverse  set  of  stakeholders.  This  section 
of  the  CONOPS  should  explain  the  message  the  CONOPS  delivers  to  each  stakeholder.  The 
CONOPS  is  intended  primarily  for  management,  developers,  and  others  in  a  management 
oversight  or  decision-making  role.  It  contains  information  of  interest  to  future  reusers  of 
product  line  assets  who  will  be  building  product  line  systems  and  to  software  professionals 
involved  with  these  systems  and  facilities  where  they  might  be  installed.  The  intent  is  to 
introduce  and  discuss  the  concepts  required  to  understand  the  product  line  approach  to 
software  development  and  acquisition. 


*  A  generative  approach  results  in  tools  that  automatically  genaate  design  or  code  for  systems. 

^  A  composition  approach  starts  with  components  that  will  be  integrated  along  with  custom  software 
to  construct  a  system.  There  may  be  compositional  tools  that  aid  the  integration  process. 
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This  section  of  the  CONOPS  should  also  provide  an  overview  of  the  contents.  The  abstract 
of  this  document  contains  a  table  that  may  serve  as  an  example  of  a  contents  description.  The 
CONOPS  is  not  intended  to  be  an  implementation  or  transition  plan  since  it  does  not  provide 
managers  with  the  detailed  steps  involved  in  planning  for  the  transition:  establishing 
accountability,  managing  risk,  scheduling,  and  budgeting.  However,  it  does  offer  a  clear 
methodology  to  realize  the  goals  and  objectives  of  the  product  line  approach  to  software 
development.  The  organization  may  be  developing  documents  that  supplement  the  CONOPS, 
or  the  CONOPS  may  be  part  of  a  large  product  line  adoption  plan.  This  section  also  provides 
a  description  of  related  information  being  developed  by  the  organization  for  the  product  line. 
For  example: 

•  A  Battlefield2000  Business  Plan  will  be  generated  for  each  phase  and  will  address 
details  of  implementing  the  CONOPS  in  that  phase.  The  Business  Plan  for  the 
Development  Phase  covers  the  roles  and  responsibilities  of  organizations 
contributing  to  the  Battlefield2000  development  effort  and  outlines  the  process  for 
interacting  with  new  Battlffield2000  reusers. 

•  The  Battlefield2000  Configuration  Management  Plan  defines  the  processes  for 
identifying,  tracking  the  status  of,  and  controlling  changes  to  software,  databases, 
and  documentation  that  are  critical  to  managing  the  Battlefield2000  baseline. 

•  The  Battlefield2000  Developer’s  Guide  documents  the  assets  available  to  software 
engineers  building  a  battlffield  C2  system.  The  guide  contains  information  useful 
in  evaluating  Battlefield2000  capabilities  with  respect  to  reuser  program 
requirements  and  in  planning  how  to  reuse  Battlefield2000  assets. 
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2  Creating  the  CONORS  Approach  Chapter 


This  section  of  the  CONORS  should  introduce  the  product  line  approach  for  developing  new 
systems.  It  should  also  introduce  an  organizational  structure  for  developing  product  line 
assets  and  fielding  the  product  line.  The  CONORS  should  explain  the  role  that  a  product  line 
architecture  and  components  will  play  in  developing  new  product  line  products.  A 
Framework  for  Software  Product  Line  Practice  [Clements  99]  offers  general  guidance  in  this 
area;  the  CONORS  should  provide  the  organization’s  implementation  of  the  Framework 
strategies.  The  chapter  is  organized  into  the  following  sections: 


Developing  new  systems 

Describes  the  specific  approach  the  organization  will  take  for 
fielding  the  product  line  assets  and  products 

Organizational  structure 

Organization  and  basic  tasks  of  product  line  roles 

2.1  Guidelines  for  Describing  the  Product  Line 
Approach  for  Developing  New  Systems 


This  section  of  the  CONORS  provides  a  brief  description  of  the  approach  for  using  product 
line,  assets  to  develop  new  systems.  A  Framework  for  Software  Product  Line  Practice 
[Clements  99]  describes  both  core  asset  and  product  development.  It  also  establishes  the 
management  role  in  orchestrating  the  product  line  approach.  This  section  of  the  CONORS 
will  elaborate  upon  the  area  of  product  development  according  to  organizational  goals  and 
constraints.  This  approach  may  result  from  top-down  asset  development,  in  which  assets  are 
developed  and  products  are  subsequently  deployed  using  those  assets,  or  a  bottom-up 
approach,  in  which  legacy  systems  and  new  developments  are  mined  for  assets  in  future 
developments.  In  either  case,  this  section  should  describe  the  approach  for  producing  new 
systems.  The  next  section  will  describe  the  management  structure  to  put  the  approach  into 
effect. 

The  Framework  describes  the  product  space,  assets,  and  production  plan  as  the  key  outputs  of 
core  asset  development.  These  outputs  are  used  in  product  development  widiin  the  product 
line.  The  CONORS  may  describe  and  illustrate  the  product  development  approach  as 
follows: 

A  development  organization  works  with  the  sponsoring  organization  and  users  to 

make  decisions  on  the  requirements  and  needs  of  a  particular  system  battltfield 
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command  and  control  system.  The  development  organization  makes  these 
decisions  and  develops  requirements  for  the  command  and  control  system  in  light 
of  the  Battl^eldlOOO  assets.  The  assets  and  architecture-based  development 
offer  the  developers  flexibility  in  deciding  which  capabilities  must  be  mission- 
unique  and  which  they  can  more  cost  fffectively  achieve  through  reuse  of 
Battltfield2000  assets.  The  sponsor  manages  the  development  arui  can  monitor 
and  validate  the  development  of  the  battlefield  command  and  control  system  as  it 
evolves  from  prototype  to  final  deployment  (Figure  1,  Part  A). 

Rather  than  bmldingfrom  scratch,  the  application  developer  uses 
Battlefield2000  assets  to  build  a  specific  product  in  the  product  line.  Product 
development  occurs  through  customization  from  base  requirements  and  a 
product  line  architecture.  The  application  development  organization  integrates 
common  software  components  and  mission-unique  software  using  generator  and 
manual  techniques.  Figure  1,  Part  B  illustrates  this  concept. 


Part  A 


Customers, 

Sponsor 


Final  Version 


Needs 


PartB 


Batttefield2000  Reuser 
Organization 


specification  and 
Architectural 
Tailoring 


Battlefield  Command 

and  Control  System 
Deployment 


"\^^Target  System 
Models  and  ^^AC^K^cluro 
Architectures 


Qualification, 
Operational 
Test  and  Evaluation 


Battlefield  C2 

Systems 


Battlefjeld2000  ^  Integration  of  Assets 

Architectures  and  ^irid  Unique  Software 

Other  Assets  Components  por  System  Development 


Figure  1.  Product  Line  Approach  for  Product  Development 


Given  the  production  plan,  the  CONOPS  should  elaborate  the  tasks  performed  by  the  user  of 
product  line  assets.  These  tasks  will  include  the  following; 

•  using  the  product  line  architecture  for  all  product  line  products 

•  integrating  product  line  component  assets  in  accordance  with  the  architecture 

•  developing  and  integrating  product-unique  component  assets  for  that  architecture 

•  providing  products  from  the  product  line  to  customers 

•  feeding  back  new  or  modified  components  to  the  asset  developers 
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supporting  the  implementation  and  maintenance  of  the  development  and  execution 
environments  for  product  line  systems 


2.2  Guidelines  for  Describing  Organizational 
Structure 


This  section  of  the  CONOPS  provides  a  brief  description  of  the  organizational  structure  for 
developing  product  line  assets  and  using  product  line  assets  to  develop  new  systems.  The 
Framework  identifies  a  number  of  fimctional  activities  within  a  product  line  organization 
including:  architecture,  component  engineering,  product  line  support,  and  product 
development.  The  CONOPS  should  describe  and  illustrate  the  specific  groups  established  by 
management  to  perform  these  functional  activities  in  fielding  the  product  line.  For  example. 

Figure  2  illustrates  four  fimctional  groups  within  the  ACAfYWorks  organization: 

•  The  ACAfYWorks  Architecture  Group  produces  the  product  line  architecture  for 
pager  products.  The  Architecture  Group  also  collaborates  in  building  specific 
applications  by  recommending  use  of  product  line  assets  to  the  Pager  Product 
Development  Groups. 

•  The  ACAfYWorks  component  engineering  group  develops  assets  within  specific 
areas  of  pager  product  expertise  for  use  in  pagers.  The  asset  group  also  defines 
and  evolves  product  line  architectures  with  the  Architecture  Groiq). 

•  The  ACAfYWorks  Product  Line  Support  Group  d^nes  the  development  and 
execution  environments  for  pager  products.  The  support  group  is  also  responsible 
for  configuration  management  of  ACAfYWorks  assets. 

•  Pager  Product  Development  Groups  develop  and  deliver  pager  products  for 
customers.  They  develop  a  target  system  architecture  using  the  product  line 
architecture  and  ACAfYWorks  components. 
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Related 
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Figure  2.  Product  Une  Oiganizational  Structure 

A  product  line  approach  Working  Group  facilitates  the  interactions  between  the 
Pager  Product  Development  Groups  and  the  other  ACMYWorks  groups. 

Working  Group  membership  includes  representatives  of  the  ACMYWorks 
management  team,  pager  marketing,  and  pager  product  developers. 

Other  organizational  groups  are  possible.  For  example: 

•  A  product  line  organization  has  an  architecture  group  but  combines  asset  and  product 
development  groups.  Under  this  structure,  component  assets  are  developed  as  a  by¬ 
product  of  the  development  of  individual  applications  in  the  product  line. 

•  Another  structure  may  share  product  development  activities  between  two  groups.  Shared 
responsibility  would  exist  when  a  product  development  is  commissioned;  the 
development  activities  will  be  performed  by  the  commissioning  organization  along  with 
the  organization  that  was  commissioned. 
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3  Creating  the  Product  Line  Background 
Chapter 


This  section  of  the  CONOPS  should  describe  the  history  of  the  product  line  and  reasons  for 
moving  to  the  product  line  approach.  This  description  should  identify  specific  developers  of 
product  line  products,  or  describe  the  characteristics  of  developers  or  products  likely  to  be 
using  product  line  assets.  Topics  to  be  covered  may  include  the  following: 

•  the  need  for  initiating  a  product  line  effort: 

•  software  with  reuse  potential  for  implementing  related  systems 

•  enterprise  goals  and  objectives  for  new  capabilities 

•  organization  targets  reductions  in  time,  risk,  and  cost  of  system  development  and 
maintenance 

•  an  understanding  of  market  demands  and  recognition  that  other  organizations  are 
considering  product  line  approaches 

•  the  inability  of  the  organization  to  meet  customer  demand  without  significant  change  in 
its  way  of  doing  business 


This  chapter  of  the  CONOPS  will  vary  depending  on  the  specific  background  information.  It 
will  generally  contain  the  following  sections: 


Background  of  the  product 
line 

Activities  in  fielding  the  product  line  leading  up  to  creation  of 
the  CONOPS 

Rationale 

Reasons  for  moving  to  the  product  line  approach 

Benefits 

Benefits  of  adopting  a  product  line  approach 

Challenges 

Issues  that  must  be  addressed  for  successful  introduction  of 
the  product  line 

Risks 

Areas  of  risk  that  should  be  addressed  in  fielding  a  product 
line 
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3.1  Guidelines  for  Describing  the  Product  Line 
Background 

This  section  of  the  CONOPS  should  present  the  relevant  history  of  the  product.  The 
organization  will  want  to  state  the  context  in  which  the  product  line  program  has  been 
developed  to  date,  lypical  product  line  activities  include  the  following: 

•  feasibility  studies 

•  assessments  of  the  extent  of  commonality  among  potential  product  line  systems 

•  analysis  of  candidate  systems  for  the  product  line 

•  market  studies  to  determine  whether  the  product  line  can  be  fielded  on  a  schedule 
consistent  with  application  developer  or  market  needs. 

Results  of  studies  and  assessments  can  be  cited  to  verify  both  high  levels  of  requirement 
commonality  and  the  ability  to  meet  schedule  constraints. 

Based  on  the  maturity  of  the  program,  the  organization  may  want  to  highlight  its 
development  plans  for  the  initial  product  line  products.  For  exang)le: 

The  BattlefieldlOOO  Program  was  initiated  in  August  199X.  Battl^eld2000 
development  is  structured  as  a  sequence  of  increments,  each  about  six  months  in 
duration.  Increment  #1,  containing  infrastructure  software,  was  completed  in 
January  199X.  Completion  of  the  total  Battlefield2000  and  initial  battlefield 
command  and  control  development  is  scheduled  for  December  199X. 

The  organization  should  state  its  own  perspective  on  product  line  assets.  For  exanq>le: 

Battl^eld2000  defines  a  reusable  software  architecture  for  battlefield  command 
and  control  systems,  a  set  of  software  libraries  supporting  the  architecture,  and  a 
production  plan  for  creating  a  battlefield  C2  system  using  the  software 
architecture  and  components.  By  providing  a  software  baseline  that  supports 
commonly  required  functionality,  and  by  maintaining  that  baseline  across  all 
reuser  programs,  Battlefteld2000  offers  savings  in  both  system  development  and 
maintenance  efforts. 

The  CONOPS,  like  the  architecture  and  other  components,  is  a  product  line  asset  and  can  be 
used  to  educate  new  developers,  provide  backgroimd  to  potential  customers,  and  serve  as 
basis  for  long-term  decisions.  The  brief  program  history  should  be  capable  of  serving  these 
as  well  as  other  needs. 
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3.2  Guidelines  to  Describe  the  Rationale  for  Moving 
to  a  Product  Line  Approach 


The  CONOPS  document  should  help  readers  understand  why  the  organization  is  making  the 

transition  to  a  new  way  of  doing  business.  Issues  that  may  be  covered  include  the  following: 

•  Current  costs  in  developing  new  systems  -  These  costs  may  be  represented  as  time  to 
market,  level  of  effort,  loss  of  market  share,  or  inability  to  keep  up  with  technolpgy. 

•  Failure  to  leverage  assets  and  experience  across  current  projects  -  The  result  is  relearning 
lessons  with  each  new  start,  loss  in  reliability,  and  diverse  training  requirements. 

•  Inability  to  deliver  increased  functionality  -  Customers  in  government  and  industry  are 
demanding  more  capabilities  of  their  software  products  to  keep  pace  with  increasing  user 
needs  and  processor  capabilities.  A  major  industrial  corporation  stopped  the  parallel 
development  of  four  new  products.  It  then  initiated  a  product  line  that  could  develop 
those  four  plus  future  products  without  having  to  recreate  ftmctionality  for  each  [Bass 
99]. 

The  CONOPS  should  clearly  state  the  specific  advantages  of  moving  to  a  product  line 

approach.  The  following  list  provides  some  possible  rationale: 

•  Development  time  and  cost  are  significantly  reduced  through  reuse  of  technology,  design, 
and  asset  qualities.  Tailorable  features  are  built  into  assets  to  meet  more  than  one  user’s 
needs. 

•  Organizations  build  core  competencies,  which  are  concentrated  areas  of  knowledge  that 
allow  them  to  make  more  productive  use  of  their  staff. 

•  Products  are  engineered  through  recognition  of  changes  within  fundamental  requirements 
or  product  line  architectures,  rather  than  built  firom  scratch. 

•  The  organization  can  provide  specific  guidance  to  suppliers  for  vendor  qualifications, 
development  standards,  and  product  definitions. 

•  Products  have  increased  quality  through  the  use  of  assets  that  are  well  understood  and 
proven  through  retesting  during  multiuse. 

•  New  technology  may  be  more  effectively  incorporated  through  sharing  of  innovations. 

•  Literoperability  increases  through  use  of  common  architectures,  interfaces,  and  protocols. 

•  Training  requirements  are  reduced  through  use  of  conunon  components. 

Each  organization  will  use  business  planning  to  establish  its  primary  product  line  drivers. 

The  organization  should  characterize  its  own  drivers  as  in  this  example: 

Major  contributors  to  the  high  cost  of  software  for  our  pager  systems  are  the 
duplication  (rf  resources  and  creation  of  multiple  systems  that  provide  the  same 
or  similar  capabilities.  Redundancy  in  systems  is  evidenced  by  the  organization 
developing  multiple  pagers  petfomung  the  same  or  similar  functions.  In 
addition,  these  systems  provide  the  same  functionality  as  existing  legacy  systems 
without  reusing  an  economically  significant  amount  of  existing  system  resources. 
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Most  systems  are  built  from  scratch,  even  though  they  duplicate  other  systems  in 
part  or  in  their  entirety. 

By  exploiting  pager  commonalities  and  controlling  the  variability  across  related 
systems,  ACMYWorks  will  provide  strategies  that  will  enable  the  development  of 
pager  systems  faster,  cheaper,  and  with  added  capability.  For  the  product  line 
concept  to  work,  a  fundamental  change  is  required  in  the  way  system 
requirements  are  defined.  The  product  groups  must  be  aware  that  they  will  be 
called  upon  to  develop  system  requirements  and  design  in  light  of  existing 
ACMYWorks  assets. 

3.3  Guidelines  for  Describing  Benefits  of  the  Product 
Line  Approach 

This  section  will  elaborate  on  the  benefits  the  organization  hopes  to  achieve  in  moving  to  a 
product  line.  As  part  of  the  decision  to  go  to  a  product  line  approach,  the  organization  will 
conduct  a  business  analysis  to  establish  product  line  goals,  objectives,  and  strategies.  For 
some,  the  motivation  may  be  to  maintain  market  share  or  technology  leadership.  For  others, 
it  is  a  matter  of  time  to  market  or  reduced  costs.  The  analysis  will  set  goals  such  as 
anticipated  reductions  in  time  to  market,  cost  savings,  and  numbers  of  systems  anticipated  for 
the  product  line.  The  CONOPS  should  elaborate  upon  these  goals  and  serve  as  an  advocate  of 
the  approach.  For  example; 

By  using  the  product  line  systems  approach,  the  Battlefield  2000 program  office 
will  deploy  systems  faster,  at  a  lower  cost,  and  with  fewer  resources.  Our  goals 
include  delivery  of  two  product  line  systems  per  year  to  battlefield  command  and 
control  users.  Based  on  results  obtained  during  proof-of-conept  system 
development,  we  anticipate  a  50%  cost  savings  in  producing  these  systems  with 
time  to  field  reduced  from  three  years  to  eighteen  months. 

System  reliability  will  increase  with  the  use  of  common  components  with  high 
reliability  and  proven  performance.  Training  will  be  improve,  since  common 
components  will  reduce  the  amount  cf  training  currently  needed  when 
transitioning  staff  between  different  systems  in  the  product  line.  More 
commercial  components  will  be  available  because  industry  will  identify  a  larger 
market  for  their  products  when  used  across  similar  systems.  Upgrades  of 
components  will  also  be  promoted  as  industry  recognizes  a  new  market  for  their 
enhanced  products. 

These  benefits  and  others  accrue  from  the  leverage  gained  through  the  reuse  made  possible  by 
the  product  line  approach.  The  CONOPS  should  list  assets  that  are  proposed  or  that  exist  for 
supporting  the  product  line.  The  following  assets  should  be  considered  for  use  across  the  product 
line: 
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•  the  product  line  architecture 

•  software  components  that  populate  the  architecture  of  each  product 

•  the  design  decisions  invested  in  those  components 

•  the  documentation  of  the  architecture  and  the  components 

•  the  performance  models  and  performance  engineering  invested  in  the  architecture  for 
each  product 

•  user  interface  design 

•  test  plans,  test  cases,  and  test  documentation  for  each  component  and  each  product 

•  processes  and  procedures 

•  personnel,  who  will  now  be  able  to  move  seamlessly  from  project  to  project  because  the 
architecture,  components,  and  development  processes  will  be  familiar  to  them  across 
projects 

•  project  schedules,  budgets,  and  work  breakdown  structures,  resulting  in  higher-fidelity 
plarming 

The  CONOPS  may  elaborate  upon  these  and  may  be  specific  about  their  use. 

3.4  Guidelines  on  Recognizing  Challenges  to 
Successful  Implemenation 


This  section  of  the  CONOPS  should  elaborate  upon  specific  challenges  and  barriers  the 
organization  has  recognized  and  is  plarming  to  address.  The  successful  inqrlementation  of  a 
product  line  approach  presents  significant  challenges;  but  these  challenges  are  surmountable 
with  adequate  plarming.  These  may  include  the  following: 

•  Cultural  -  Product  line  strategies  mean  organizations  and  managers  have  less  direct 
control  over  their  product  developments  and  increased  dependency  on  other 
organizations  to  understand  their  requirements  and  provide  acceptable  solutions.  Giving 
up  this  control  and  the  necessary  dollars  to  support  product  line  technology  and 
application  development  may  be  difficult. 

•  Strategic  planning  -  Product  line  plarming  is  not  only  a  management  process  that  links 
related  systems.  The  organization  must  consider  the  long-term  needs  of  users  and  the 
ability  to  build  products  for  those  users.  The  organization  must  take  an  enterprise-wide 
look  at  existing  and  plarmed  products  and  look  several  years  into  the  future  in  plarming 
for  product  lines.  The  future  year  development  plans  should  focus  attention  on  product 
lines  as  the  means  to  satisfy  the  plan. 

•  Need  for  tradeoffs  -  The  product  line  approach  presents  a  tradeoff  for  the  user  between 
“Build  me  the  exact  system  I  want”  and  “Build  me  a  system  almost  like  what  I  want, 
using  the  product  line  and  saving  on  costs  and  time.” 

•  Resource  ownership  -  Who  will  “own”  the  product  line  assets?  How  will  they  be  fimded? 
These  issues  require  transitioning  from  individual  product-focused  organizations  and 
budgets  to  a  set  of  shared  products  and  budgets. 
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•  Recognition  and  reward  -The  current  system  focuses  on  recognition  and  rewards  for 
personnel  on  delivered  systems.  Use  of  product  line  strategies  also  necessitates  a  shift  to 
rewarding  and  advancing  personnel  for  broadening  the  utility  of  products  and  facilitating 
their  use  within  and  across  product  lines. 

•  Effects  of  technological  change  -  The  transition  to  a  product  line  approach  will  mean 
significant  changes  in  our  current  way  of  doing  business.  We  must  plan  for  the  effects 
this  will  have  on  the  individuals  who  must  carry  out  the  transition  and  also  on  those  who 
will  be  operating  under  the  new  approach. 

•  Effectiveness  of  approach  -  The  product  line  approach  must  be  measured  in  order  to 
judge  its  effectiveness.  Measurements  may  include  typical  software  development 
metrics,  but  these  must  be  adjusted  to  account  for  the  development  and  sustainment  of 
assets  along  with  the  use  of  assets  in  application  engineering.  Important  measures  will 
include;  amount  of  change  that  assets  must  undergo  for  use  in  individual  products, 
defects,  assets  that  are  or  are  not  being  used,  and  time  to  market. 

3.5  Guidelines  for  Describing  Product  Line  Risks 


Introducing  a  product  line  in  an  organization  carries  with  it  several  areas  of  risk.  This  section 

of  the  CONOPS  should  list  and  elaborate  upon  these.  The  following  are  examples; 

•  Failure  to  identify  a  product  line  champion-  Success  of  the  product  line  requires  strong 
management  in  the  form  of  a  product  line  champion.  For  most  organizations,  the  non¬ 
technical  challenges  alone  will  limit  success  unless  one  individual  is  given  and  assumes 
management  responsibility.  The  technical  activities  involved  in  fielding  a  product  line, 
from  conceptualization,  to  asset  development,  to  producing  the  first  products  may  take 
several  years  during  which  no  hard  products  are  released.  The  champion  must  maintain 
the  vision  during  this  “black  hole”  period.  In  particular,  the  product  line  champion  needs 
to  take  the  early  initiative  and  personally  oversee  the  development  of  a  CONOPS  to 
solidify  the  conceptual  approach  and  obtain  the  buy-in  of  key  stakeholders.  The 
champion  must  have  authority  to  direct  resources  and  establish  a  schedule  that  supports 
the  long-term  product  line  goals. 

•  Lack  of  appropriate  product  line  vision  -  A  CONOPS  will  often  be  written  two  or  more 
years  before  assets  are  built  and  products  start  to  flow  from  the  product  line.  The 
developers  of  the  CONOPS  must  focus  attention  on  an  end  state — ^where  the  product  1in<» 
should  be  anywhere  from  three  to  ten  years  hence  in  order  to  plan  for  a  full  transition. 
The  organization  must  be  able  to  address  the  development  of  assets,  their  use  in  specific 
products  and  their  refinement,  and,  potentially,  the  transition  of  the  product  line  approach 
throughout  the  enterprise. 

•  Failure  to  maintain  the  CONOPS  -  The  CONOPS  is  not  meant  to  be  complete  and  placed 
on  a  shelf.  It  should  be  constantly  reviewed  and  revised  as  the  product  line  is  fielded  and 
the  product  line  evolves.  As  a  document  released  early  in  the  process  of  fielding  a 
product  line,  the  CONOPS  can  only  provide  a  starting  point  for  product  line 
development.  Lessons  learned  in  asset  development,  initial  product  development  using 
assets,  and  sustainment  of  the  assets  must  be  factored  back.  If  the  CONOPS  is  not 
maintained,  at  least  in  spirit  if  not  as  a  formal  document,  the  product  line  may  not 
successfully  evolve  to  address  new  customer  needs. 
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4  Developing  the  Organizational 
Considerations  Chapter 


This  chapter  of  the  CONOPS  should  describe  some  of  the  key  organizational  management 
issues  associated  with  fielding  a  product  line.  To  complete  this  section,  an  organization  must 
address  several  of  the  key  CONOPS  issues.  Also,  there  are  specific  start-up  activities  that 
must  be  initiated.  This  section  should  also  be  tailored  to  address  action  planning  for  the 
organization. 

The  product  line  approach  is  not  a  case  of  “one  size  fits  all.”  There  are  circumstances  where 
the  approach  should  not  be  followed  because  of  costs,  scheduling,  performance,  capability,  or 
insufficient  commonality.  A  new  set  of  requirements  may  fall  outside  the  bounds  of  the 
existing  product  line  assets.  The  product  line  organization  must  then  determine  if  these 
requirements  should  be  a  new  area  for  continuing  work  or  whether  establishing  a  new 
product  line  is  recommended.  All  of  these  factors  must  be  considered  as  part  of  the  business 
analysis  for  meeting  needs  of  candidate  users.  The  CONOPS  should  establish  the  process  or 
the  organizational  groups  that  will  make  these  decisions.  This  chapter  is  organized  into  the 
following  sections: 


Section  Number  and  Topic 

Description 

4.1 

Product  line  champion 

Describes  identification  of  a  champion  who  will  assiune 
responsibility  for  managing  and  facilitating  the  product  line 
effort 

1 

Architecture-based 

development 

Establishes  a  development  process  centered  on  software 
architecture  to  address  common  and  mission-unique 
requirements 

1 

Impact  of  transition 

Addresses  the  impact  of  change  on  organization, 
management,  and  acquisition  elements 

1 

Support  strategy 

Explains  roles  played  in  the  continued  maintenance  and 
enhancement  of  the  product  line 
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4.1  Guidelines  for  Describing  the  Selection  of  a 
Product  Line  Approach  Champion 

This  section  of  the  CONORS  elaborates  upon  the  importance  of  designating  a  leader  for 
fielding  the  product  line.  The  benefits  of  the  product  line  approach  will  not  be  realized  by  just 
creating  a  set  of  loosely  related  components  that  attack  selected  specific  (or  overlapping) 
aspects  of  the  problem.  Product  line  systems  are  built  from  software  components  that  are 
designed  (or  reengineered  from  existing  systems)  for  systematic  reuse  across  the  product  line. 
This  systematic  approach  to  reuse  requires  a  systems  perspective  and  a  comprehensive  plan 
that  identifies  all  of  the  measures  leading  to  success  and  the  means  of  ensuring  their 
accomplishment.  A  product  line  champion  is  the  key  player  in  achieving  the  success  of  the 
product  line. 

Understanding  potential  user  needs,  implementing  solutions,  and  managing  product  evolution 
goes  beyond  creation  of  an  architecture  and  conq>onents.  It  requires  a  systematic  and 
comprehensive  approach  (i.e.,  the  product  line  concept  of  operations)  to  marshal  existing 
resources  and  identify  additional  methods  to  lower  the  costs  of  providing  product  capabilities 
through  use  of  product  line  assets.  Key  to  this  is  strong  management  support  and  the 
identification  of  a  champion  who  will  assume  responsibility  for  managing  and  facilitating  the 
effort.  This  section  of  the  CONOPS  addresses  the  following  key  question: 

IssiK  §3:  Who  isAvill  be  the  product  line  champion? 

The  champion  must  be  the  owner  of  the  CONOPS  and  employ  available  resources  in  concert 
with  each  other  and  according  to  the  plan  established  in  the  CONOPS.  For  example: 

For  the  Battlefield2000  effort,  the  Battlefield2000 program  manager  has  been 
designated  the  product  line  champion,  and  is  responsible  for  defining  and 
articulating  the  integrated  vision  for  Battlffield2000  assets  and  the  battlefield 
command  and  control  product  line. 

4.2  Guidelines  for  Describing  the  Importance  of 
Architecture-Based  Development 

Software  product  line  results  are  predicated  on  the  use  of  architecture-based  development 
approaches.  Much  is  implied  by  this  approach  to  system  design.  This  section  of  the 
CONOPS  should  establish  a  development  process  centered  on  a  software  architecture  to 
address  common  and  mission-unique  requirements  and  applied  to  the  development  of  the 
system  in  a  prescriptive  manner. 
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The  architecture-based  development  approach  requires  that  a  number  of  related  elements  be 
brought  together  to  manage,  design,  implement,  and  test  the  system.  The  CONOPS  may 
include  or  point  to  the  following: 

•  a  set  of  program  plans  (program  management  plan,  systems  engineering  management 
plan,  software  development  plan,  configuration  management  plan,  test  and  evaluation 
plan,  integration  plan,  etc.) 

•  the  architecture  description  document 

•  a  set  of  architectural  templates  or  tools  that  automate  the  representation  and  use  of  the 
product  line  architecture 

•  typical  development  tools  including  those  for  detailed  design  and  coding,  configuration 
management,  compilers,  grrqihical  user  interface  builders,  etc. 

•  documentation  tools 

Program  plans  should  establish  the  management  infrastructure  and  reporting  elements  similar 
to  the  structure  of  the  architecture.  The  processes  of  estimation  and  tracking  should  be 
directly  keyed  to  this  structure.  The  program  schedule  needs  to  reflect  a  commitment  of 
resources  and  time  during  early  phases  of  the  program  for  development  and  validation  of  the 
architecture.  This  usually  includes  sufficient  prototyping  to  effect  validation  of  architectural 
decisions  and  discover  detail  about  unprecedented  parts  of  the  system. 

The  CONOPS  may  list  the  assets  that  are  developed,  commissioned,  or  purchased  for 
supporting  architecture-based  development.  One  group  may  be  a  set  of  composition  tools  for 
generating  system  instances  from  components  that  are  corr^liant  with  the  architecture.  The 
assets  may  include  infrastructure  components  that  provide  system-wide  services  and 
structural  backbone  used  by  rq)plication  components.  They  handle  such  issues  as  scheduling, 
message  management,  time  management,  security,  marshaling  operating  platform  services, 
synchronization,  etc.  Assets  also  include  application  corr^onents  that  provide  specific 
functionality  related  to  domains  of  the  product  line  and  system  functional  requirements. 

The  CONOPS  should  address  the  relationship  of  the  architecture  to  other  product  line  assets 
and  to  products  buUt  from  those  assets.  This  addresses  another  key  question: 

Issue  #4:  What  is  the  relationship  between  the  product  line  arul  product  line 
assets,  especially  the  architecture? 

As  part  of  the  architecture  development  a  number  of  artifacts  are  created  that  are  generally 
considered  part  of  the  architecture.  These  may  include  the  following: 

•  architecture  exploration  and  tradeoffs 

•  architecture  definition 

•  cothmunication  of  architecture  in  documentation 

•  definition  of  software  components 
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•  rules  for  architecture  conformance 

•  technology  forecasts 

The  CONOPS  should  describe  the  basic  contents.  For  example: 

Architecture  is  a  critical  asset  ofACMYWorks  development.  The  architect’s 
responsibility  includes  architecture  exploration  and  definition  that  will  satisfy  the 
needs  of  the  product  line  in  general  and  the  individual  products  in  particular. 

Equally  important,  the  architect  must  communicate  the  architecture  to  those  who 
will  be  building  ACMYWorks  components  and  those  who  will  be  building 
products.  The  architecture  defines  those  software  components  that  ate  candidates 
to  become  core  assets.  Conformance  rules  must  be  put  in  place  for  ensuring  that 
the  products  in  the  product  line  conform  to  the  architecture;  that  is,  that  no 
product  begins  to  go  its  own  way  and  depart  from  the  overall  architectural 
scheme.  The  architect  is  also  responsible  for  ensuring  that  die  architecture 
remains  viable  over  the  life  of  the  product  line;  this  responsibility  may  require 
technology  forecasting. 

4.3  Guidelines  for  Describing  the  Impact  of 
Transition  to  the  CONOPS 

This  section  of  the  CONOPS  elaborates  upon  the  transition  to  the  product  line  approach.  This 
transition  may  require  significant  change  in  existing  organizations.  While  the  CONOPS  is 
not  itself  a  transition  plan,  the  CONOPS  should  briefly  address  the  impact  of  change  on 
organization,  management,  and  acquisition  elements.  These  areas  will  be  covered  in  greater 
depth  within  a  transition  plan  or  other  documents. 

4.3.1  Impact  on  Organization 

The  product  line  approach  requires  special  attention  to  bring  together  core  conqietencies  from 
across  existing  organizational  stractures.  The  CONOPS  should  describe  an  approach  that 
will  reduce  or  eliminate  redundancy  of  personnel  and  skills  within  the  current  project- 
oriented  organizations.  This  should  definitely  be  the  case  if  the  organization  develops 
products  in  house.  Where  an  organization  commissions  the  product  line,  there  will  likewise 
be  a  consolidation  of  expertise  that  currently  supports  or  manages  individual  systems. 

Product  line  organizational  restmcturing  will  enable  concentration  and  sharing  of  personnel 
and  skills,  leading  to  greater  overall  productivity.  A  specific  action,  then,  is  the  following: 

Action:  Designate  a  product  line  champion  with  sufficient  organizational 
visibility  and  respect,  and  with  enough  decision-making  capability  and  authority 
to  manage  and  champion  the  product  line  creation  and  sustainment  effort. 
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The  product  line  approach  will  affect  numerous  stakeholders,  including  sponsors, 
contractors,  and  support  organizations.  Those  actually  developing  product  line  assets  will 
operate  with  a  totally  new  set  of  responsibilities.  Users  of  the  product  line  assets,  those 
developing  products  in  the  product  line,  will  experience  significant  change  in  their  way  of 
doing  business.  The  CONOPS  should  describe  the  new  interactions  between  asset  reusers 
and  other  stakeholders.  For  example: 

As  users  of  BattlefieldlOOO  assets,  battlefield  command  and  control  system 
developers  will  coordinate  their  development  with  the  BattlefieldlOOO 
architecture  group.  These  product  programs  will  rely  on  both  the  BattlefieldlOOO 
Program  and  its  component  development  group  for  technology  expertise.  The 
product  development  gratis  for  mission-unique  systems  will  establish  the 
specifics  for  system  requirements,  performance,  design,  and  implementation 
based  on  BattlefieldlOOO  assets.  As  part  ofBattl(field2000  sustainment,  the 
Battlefield2000  Program  will  review  the  existing  product  line  and  architecture 
and  establish  a  reasonable  maintenance/upgrade/enhancement  plan  for 
Battltfield2000  based  on  the  results  obtained  fiom  product  programs. 

4.3.2  Management 

New  incentives  will  be  needed  to  support  the  management  and  use  of  a  product  line 
approach.  The  CONOPS  should  spell  out  those  steps  that  will  help  manage  the  technological 
changes  diat  come  with  adopting  a  product  line  approach: 

•  addressing  promotion  and  reward  potential  as  it  relates  to  product  line  goals  and 
processes  in  the  new  structure 

•  making  general  cultural  changes  at  all  levels,  including  breaking  the  “not  invented  here 
syndrome”;  management  must  drive  these  changes,  even  when  they  are  the  most  affected 

•  integrating  efforts  across  organizational  boundaries  in  order  to  get  the  job  done — ^i.e., 
developing  a  system  by  relying  on  support  and  assets  from  other  parts  of  the  organization 
or  other  organizations;  not  all  aspects  of  a  program  will  be  under  the  control  of  one 
manager,  and  this  will  require  some  culturd  changes 

•  sharing  of  responsibilities  and  resources  that  is  impossible  in  a  stovepiped  organizational 
structure 

•  supporting  certification  of  system  conformance  to  the  product  line  architecture  and 
successful  use  of  product  line  assets 

•  recognizing  that  the  development  of  mission-unique  applications  requires  more  than  just 
component  integration 

A  specific  action  established  by  the  CONOPS  should  be  the  following: 

Action:  Create,  adopt,  and  communicate  policies  that  incentivize  and  reward  the 
success  of  the  product  line  over  the  success  of  individual  products. 
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4.3.3  Development  or  Acquisition  Policies 

Under  the  product  line  approach,  systems  will  be  developed  or  acquired  through  methods  that 
encourage  the  use  of  existing  product  line  infrastructure.  The  organization  must  adopt 
policies  that  directly  support  the  maintenance  and  upgrade  of  the  infrastructure  to  support 
future  needs.  The  current  development  or  acquisition  process  provides  resources  for 
software-intensive  efforts  on  a  product-by-product  basis,  with  minimal  resources  allocated  to 
product  line  infrastructure.  More  investment  is  needed  in  support  of  a  series  of  systems  based 
on  a  common  infrastructure. 

The  CONOPS  should  address  many  near-term  changes  to  development/acquisition  strategies. 
These  strategies  include  the  following: 

•  coordination  of  development  activities  among  product  line  system  projects  and  programs 

•  elimination  of  redundant  development 

•  use  of  resources  to  further  the  development  of  the  product  line  for  the  benefit  of  all  the 
contributing  projects  and  programs 

The  product  line  organization  may  pool  funds  from  all  the  systems  that  fall  within  a  product 
line  to  pursue  product  line  development.  For  in-house  development,  a  special  project  may  be 
established  to  manage  the  common  infrastructure.  Other  projects  would  contribute  funding 
and  software  assets  to  evolve  the  product  line.  Existing  projects  may  be  taxed — even  if  they 
do  not  use  the  assets — ^as  an  incentive  to  adopt  the  product  line  approach.  For  acquisition  via 
commissioning  or  purchase,  individual  projects  may  be  taxed  to  cover  these  costs  plus  those 
of  long-term  sustainment.  The  CONOPS  should  establish  the  following: 

Action:  Create  and  adopt  policies  to  decide  how  the  genetically  reusable  core 
assets  will  be  paid  for. 

Management  must  ensure  that  every  new  start  or  major  upgrade  is  examined  for  potential 
inclusion  in  the  product  line.  This  examination  looks  for  similarities  with  existing  systems  in 
mission  and  underlying  functions.  The  goal  is  to  focus  new  development  on  unprecedented 
areas  and  reuse  product  line  assets  as  much  as  possible.  Reuse  of  assets  includes  much  more 
than  software  components.  Design,  architecture,  requirements,  and  models  are  all  assets  for 
reuse.  Policies  will  need  to  ensure  that  each  procurement  leverages  past  investments  to  the 
fullest  and  contributes  to  assets  used  in  future  efforts. 

The  CONOPS  should  increase  the  focus  on  assets  (including  non-code  assets,  such  as 
architectures)  and  their  management  for  use  across  more  than  one  system.  Use  and  evolution 
of  product  line  assets  is  a  key  question.  The  organization  should  establish  policies  that  assure 
control  over  the  development  and  evolution  of  the  product  line  architecture.  Every  system 
requirement  that  comes  to  a  product  line  organization  need  not  be  accepted,  however.  The 
CONOPS  should  establish  the  following: 
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Action:  Adopt  and  disseminate  a  policy  stating  the  criteria  to  be  applied  in 
determining  whether  a  new  product  should  be  developed  using  product  line 
assets,  when  the  assets  will  be  extended  to  support  a  new  product  and  when  a 
new  product  is  rejected  as  being  out  of  scope. 

4.4  Guidelines  for  the  Product  Line  Sustainment 
Strategy 

This  section  of  the  CONOPS  describes  the  approach  for  the  continued  maintenance  and 
enhancement  of  the  product  line  and  the  corresponding  architecture.  The  CONOPS  should 
describe  roles  throughout  the  entire  organization  that  cooperate  in  this  effort,  with  the  group 
assuming  the  architecture  role  taking  the  lead.  Architecture  maintenance  and  enhancement 
may  include  architecture  assessments  to  determine  the  needs  for  enhancement  or,  possibly,  a 
new  architecture.  Component  development  may  include  actual  enhancements  to  product  line 
components  and  ensiuing  that  new  versions  of  COTS  products  are  integrated  into  the  product 
lines.  Product  line  support  should  include  working  with  vendors  to  coordinate  maintenance 
of  their  products.  The  CONOPS  also  provides  for  updating  products  for  the  various 
customers/users  according  to  maintenance/upgrade  agreements  established  at  the  initiation  of 
a  system  development  or  acquisition.  The  maintenance  and  support  of  the  product  line 
architectures  and  components  are  a  natural  consequence  of  the  product  line  development 
strategy. 

The  support  strategy  varies  according  to  the  approach  for  asset  procurement,  use  of  assets  and 
control  of  assets.  The  following  examples  show  differing  support  strategies; 

•  Where  development  and  use  is  in  house,  the  in-house  group  performing  the  support  role 
assumes  responsibility  for  sustainment. 

•  Commissioned  assets  may  be  maintained  in  house  or  by  a  contractor.  The  sustainment 
contractor  may  not  be  the  original  developer  of  the  assets. 

•  If  assets  are  given  to  another  organization  to  be  used  in  a  commisioned  product 
development,  the  product  developer  has  little  control  over  asset  maintenance. 

•  Where  assets  are  acquired  off  the  shelf,  the  acquiring  organization  is  dependent  on  the 
asset  development  organization  to  maintain  the  assets,  and  may  have  a  limited  role  in 
determining  the  course  of  their  evolution. 

The  organization  developing  a  CONOPS  must  use  these  factors  in  establishing  its 
sustainment  strategy  for  assets  and  for  asset  use  in  products. 
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5  Developing  the  Technical 
Considerations  Chapter 


This  section  of  the  CONOPS  establishes  the  product  line  approach  in  detail.  There  are 
specific  start-up  activities  that  must  be  initiated,  and  the  CONOPS  must  provide  a 
recommended  set  of  actions.  In  a  CONOPS  document,  this  section  presents  the 
considerations  for 

•  phased  inq>lementation  of  the  product  line  approach 

•  role  of  architecture 

•  identification  and  maintenance  of  product  line  assets 

•  development  and  execution  environments 

•  evaluation  process  for  candidate  users  of  assets 


This  section  of  the  CONOPS  may  also  include  scenarios  for  product  line  asset  development 
and  product  line  system  production.  The  chapter  is  organized  into  the  following  sections: 


Section  and  Topic 

Description 

5.1 

Phased  implementation 

Identifies  phases  in  the  process  of  fielding  a  product 
line 

5.2 

Roles  and  responsibilities 

Describes  roles  and  responsibilities  for  domain 
engineering  and  the  relationship  between  the  domain 
and  application  engineering  organizations 

5.3 

Architecture  definition 

Establishes  significance  of  architecture  for  product 
line  definition,  con^nent  development,  and  product 
development 
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Identification  and 
maintenance  of  assets 

Defines  activities  required  to  identify  and  maintain 
product  line  assets  including  COTS 

5.5 

Development  and  execution 
environments 

Describes  the  role  of  the  asset  support  group  in 
producing  environments  for  development  of  assets 
and  for  application  support 

5.6 

Working  with  potential 
product  line  users 

Describes  process  for  determining  when  a  system  is 
appropriate  for  development  within  the  product  line 

■ 

Development  process 

Describes  process  used  to  create  assets  and  use  them 
in  developing  products 

5.1  Guidelines  for  Establishing  a  Phased 

Implementation  for  Fielding  a  Product  Line 

This  section  of  the  CONOPS  describes  a  plan  for  fielding  a  product  line  through  phases  over 
a  period  of  time.  The  titles  of  these  phases  (e.g.,  development)  reflect  the  primary  activity 
during  the  phase.  However,  the  development  of  products  and  processes  will  not  be  limited  to 
any  one  phase.  In  fact,  the  primary  activities  of  the  product  line  approach  (e.g..  Domain 
Engineering)  will  be  a  part  of  all  phases.  The  phases  generally  described  in  a  CONOPS  and 
the  primary  activities  for  each  include  the  following: 

•  asset  development  -  creating  the  product  line  architecture  and  other  assets;  trial  use 

•  asset  sustainment  and  product  development  -  using  the  architecture  and  assets  for 
creating  product  line  systems;  improving  the  assets  and  refining  processes  for  domain 
and  application  engineering 

•  product  line  sustainment  and  improvement  -  routine  sustainment  of  assets  and  products; 
institutionalizing  product  line  practices  across  the  enterprise 

The  activities  of  these  phases  may  be  spread  across  several  years  as  shown  in  Figure  3. 
Preceding  development,  there  may  be  an  investigative  phase  as  well,  to  explore  feasibility, 
market  conditions,  financial  considerations,  etc.  The  CONOPS  is  usually  a  product  of  that 
investigative  phase  capturing  decisions  made  in  determining  a  product  line  course  of  action. 
This  section  of  the  CONOPS  will  address  three  major  issues: 

Issue  #5;  How  will  the  product  line  be  introduced? 

Issue  #6:  What  is  the  strategy  beyond  product  line  asset  development? 

Issue  #7;  Who  are  the  users  of  product  line  assets? 
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Years  2-3 


Years  4- 


Figure  3.  Product  Line  Approach  Over  Time 


Table  5  shows  for  each  phase  the  primary  outputs,  both  products  and  processes. 


Phase 

Products 

Processes 

Asset  development 

•  Baseline  product  line  assets 

•  Reuser’s  guide 

•  Repository  and  configuration 
management  plan  and  systems 

•  Operational  plan  for  asset 
sustainment  and  product 
development  phase 

•  Assessments  (architecture,  case 
study,  etc.) 

•  Domain  engineering 
infrastructure  (tools,  methods, 
metrics,  training) 

•  Mining  assets  from  legacy 

•  Partial  application  engineering 
infrastructure 

•  Assessment  methods 
(architecture,  reuse,  etc.) 

Asset  sustainment 
and  process 
refinement 

•  Multiple  product  line  systems 

•  Improved  product  line  assets 

•  Application  developer’s  guide 

•  Operational  plan  for  product  line 
institutionalization 

•  Assessments 

•  Application  engineering 
infrastructure 

•  Feeding  back  new  assets 

•  Reengineering  of  legacy  systems 

•  Maintenance  of  systems  in  the 
product  line 

Product  line 

sustainment  and 
improvement 

•  Multiple  product  line  systems 

•  Improved  product  line  assets 

•  Product  line  maintenance  guide 

•  Product  line  production 

•  Management 

Tabie  5.  Phased  ImpiemenMion  of  Product  Line  Approach 
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Variation 

Effect 

Product  line  attributes 

A  mature  product  line,  with  significant  legacy,  will 
generally  allow  for  a  more  efficient  development 
phase. 

Asset  procurement  approach 

Asset  procurement  approaches  (develop  in  house, 
commission  or  buy)  will  affect  the  activities.  Table  5 
assumes  in-house  development.  These  activities  will 
largely  be  pursued  by  an  organization  that  is 
commissioned  to  develop  assets  for  another 
organization.  Where  a  “buy”  approach  is  used,  the 
organization  wiU  emphasize  selection  criteria. 

Asset  categories 

The  asset  categories  will  have  an  impact  on  phasing.  If 
an  architecture  already  exists,  or  can  be  adapted  from 
legacy,  there  will  be  a  strong  emphasis  on  assessing 
that  architecture  and  moving  quickly  to  a  sustainment 
phase.  If  not,  significant  effort  must  go  into 
architecture  exploration,  development  and  assessment. 

Asset  development  approach 

Development  approach  (greenfield,  legacy, 
evolutionary):  new  starts  generally  carry  significant 
risk  and  the  organization  must  plan  for  this  during  the 
development  and  early  sustainment  phases. 

Use  of  assets  in  application  engineering 

Use  of  assets  (complete/partial  system,  frequency  of 
use  in  product  development,  longevity  of  product  line): 
the  types  of  products  will  vary  based  on  these 
parameters. 

Control  over  assets 

Control  over  assets  (used  internally,  internal  and 
external  use,  made  available  for  external  use):  where 
assets  are  purchased,  control  may  be  limited  to 
participation  in  a  user’s  group.  Phasing  may  be  quite 
different.  The  CONOPS  may  describe  phases  of 
survey  (determine  if  assets  exist  in  the  marketplace), 
limited  use  (assurance  that  assets  deliver  on  promised 
potential),  and  full  production. 

Table  6.  Variations  to  Consider  in  Forumulating  the  CONORS 


The  next  subsections  provide  guidance  for  describing  specific  phases  in  fielding  a  product 
line.  The  phasing  will  vary  among  organizations,  but  the  guidelines  will  apply  with  tailoring 
if  another  phasing  is  adopted. 

5.1.1  Development  Phase 

As  stated  above,  the  CONOPS  is  usually  a  product  of  a  product  line  feasibility  examination. 
Before  initiating  the  product  line  effort,  the  product  line  organization  will  take  an  enterprise¬ 
wide  look  at  its  products.  An  inqmrtant  first  step  is  segmenting  these  products  into  product 
lines  through  an  identification  and  scoping  process.  Another  part  of  this  step  is  mission  area 
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analysis  to  define  the  business  plan  and  to  develop  the  organizational  structure  for  product 
line  development. 

The  next  steps  in  the  decision  process  during  development  include  product  line  and 
architecture  specification  to  guide  the  tailoring  of  taiget  system  architectures  for  individual 
products.  These  are  the  primary  domain  engineering  activities.  The  CONORS  will  provide  a 
brief  overview.  This  may  be  generic  to  many  product  lines: 

•  Scoping  and  specification  of  the  product  line.  Product  line  scoping  defines  the 
bounds  for  systems  that  will  constitute  the  product  line.  Scoping  also  includes 
identifying  those  entities  with  which  product  line  systems  will  interact  [e.g.,  the 
product  line  context)  as  well  as  the  goals  to  be  achieved  by  product  line 
development.  Specification  requires  understanding  the  potential  commonalities 
across  current  and  future  systems  in  the  product  line  as  well  as  variations  that  lead 
to  different  systems.  This  key  step  requires  analysis  of  product  line  capabilities, 
those  that  are  mandatory  for  each  system  in  the  product  line,  and  those  that  may  be 
optional.  In  addition,  the  definition  must  provide  for  alternative  capabilities,  i.e.,  a 
choice  among  multiple  capabilities,  where  only  a  single  choice  is  possible. 

•  Development  of  the  product  line  architecture.  The  architecture  for  the  product 
d^nes  the  components  (mandatory,  optional,  alternative),  component 
interrelationships,  constraints,  and  guidelines  for  use  and  evolution  in  building 
systems  in  the  product  line.  The  architecture  must  support  common  capabilities 
identified  in  the  specification  and  the  potential  variability  within  the  product  line. 
The  architecture  supports  the  development  of  target  system  architectures  for 
specific  product  line  systems  (see  Figure  4).  Architecture  tailoring  guidelines 
discuss  factors  involved  in  the  use  and  evolution  of  the  architecture. 

•  Development  of  component  assets.  During  the  asset  development  phase,  the 
program  will  rely  heavily  on  “mining”  cf  assets  from  existing  programs  and  may 
purchase  COTS  assets.  The  architecture  will  provide  constraints  and  guidelines 
for  development  <ff  these  assets. 

During  the  development  phase,  there  will  generally  be  one  or  more  pilot  applications  built 
using  the  assets.  These  applications  will  verify  the  ability  of  the  assets  to  meet  taiget  system 
requirements  and  will  support  development  of  the  application  engineering  process.  The 
CONORS  may  also  spell  out  activities  specific  to  a  particular  product  line: 

During  this  phase,  representatives  fwm  ACMYWorks  and  potential  ACMYWorks 
reusers  form  a  product  line  architecture  selection  team.  This  team  collaborates 
in  product  line  production  with  the  objective  of  determining  architecture 
suitability  for  a  specific  new  system.  The  team  must  assess  the  ability  of  the 
product  line  architecture  to  meet  the  specific  system  requirements  as  defined  by 
the  user.  This  architecture  assessment  considers  existing  products  in  the  product 
line,  as  well  as  architectural  constraints.  Existing  pager  products  may  serve  as  a 
model  for  the  new  system  or  the  product  line  assets  may  support  a  prototyping 
capability. 
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The  CONOPS  should  provide  an  alternative  course  of  action  if  requirements  for  a  new 

system  cannot  be  met  within  the  current  product  line  architecture.  For  example: 

•  Can  the  system  requirements  be  relaxed,  so  that  the  existing  product  line  architecture  can 
be  used? 

•  Is  it  feasible  to  use  parts  of  the  product  line  architecture? 

•  Can  the  product  line  architecture  be  extended  for  new  mission-unique  requirements  and 
for  future  systems  in  the  product  line. 

•  What  other  development  or  acquisition  approaches  are  feasible  if  the  product  line  cannot 
be  used? 

Figure  4  summarizes  die  activities  during  the  Development  Phase. 
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Figure  4.  Development  Phase  Activities 


Specific  actions  that  may  be  recommended  within  this  area  include  the  following: 

Action:  Adopt  a  schedule  and  plan  for  organizational  units  to  join  the  product 
line  effort.  Joining  may  involve  active  participation  in  the  construction  of  core 
assets  and  derived  products,  or  it  may  involve  personnel  training  to  set  the  stage 
for  more  active  participation  in  the  future,  or  it  may  involve  participation  in 
working  groups  to  review  the  architecture  and  core  asset  design. 

Action:  Designate  the  organizational  units  to  take  part  in  a  demonstration  pilot 
of  product  line  capabilities. 

Action:  Designate  and  schedule  an  initial  (pilot)  demonstration  of  the  product 
line  production  capability. 
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Action:  Choose  the  pilot  products  to  be  produced  from  the  product  line  core 

assets. 

Action:  Schedule  their  delivery. 

Action:  Plan  and  execute  a  measurement  program  for  the  pilots. 

Action:  Build  the  pilot  products. 

Action:  Assess  the  success  or  failure  of  the  pilot  effort,  and  plan  improvements. 

5.1.2  Asset  Sustainment  and  Product  Development  Phase 

During  this  phase,  the  organization  will  sustain  the  assets  and  begin  to  perform  routine 
development  of  products  within  the  product  line.  The  CONOPS  should  describe  the  process 
for  developing  products  as  that  process  is  refined,  moving  from  individual  pilot  efforts  to 
full-scale  developments.  The  CONOPS  should  describe  how  the  application  engineering 
effort  differs  from  the  current  historical  process.  For  exanqrle: 

•  Development  from  product  line  architectures  -  A  group  of  related  systems  shares  a 
common  structure  defined  as  the  product  line  architecture.  This  architecture  must 
support  interoperability  and  component  sharing  with  systems  developed  outside  the 
product  line.  A  new  system  is  built  by  using  the  product  line  architecture  to 
produce  a  target  system  architecture  from  which  an  implementation  is  constructed. 

•  Development  using  product  line  assets  -  New  systems  are  composed,  adapted,  or 
generated  by  populating  a  target  system.  To  the  greatest  degree  possible,  the  target 
architecture  uses  existing  product  line  assets.  Dus  approach  to  development 
includes  formal  tracking  of  the  product  line  assets  and  identification  of 
opportunities  for  reuse  of  the  assets  in  other  product  lines.  The  new  system 
architecture  and  any  developed  or  modified  assets  become  core  assets  for  future 
development  in  the  product  line. 

•  Development  using  common  environment  -  Products  of  the  domain  engineering 
phase  include  tools  and  methods  for  component  and  application  development. 

These  will  become  standards  for  both  the  support  and  execution  environment 
during  the  asset  sustainment  and  product  development  phase. 

The  CONOPS  should  also  defme  sources  of  variation  among  product  line  products.  Table  7 
lists  some  of  the  factors  that  contribute  to  potential  variation.  During  the  sustainment  phase, 
these  sources  will  be  planned  for  and  effectively  managed. 
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Source  of  Variation 

Description 

System  target 
environment 

•  Customer  sites 

•  Interfacing  systems 

•  Use  of  specific  products 

•  System  workload 

•  Operations  and  logistics 

Target  support 
environment 

•  Development  facilities 

•  Prototyping  facilities 

•  Maintenance  facilities 

•  Integration  and  test  facilities 

Customer/user 

•  Oiganizational  components 

•  Policies,  guidelines,  Md  standards 

•  Resources 

•  Tools  and  facilities 

•  Training  level  and  support 

•  Technology  transition  support 

Product  line 

limitations 

•  Functional  capabilities 

•  Performance  constraints 

•  Alternative  algorithms,  models,  or  implementations 

•  Information  representation 

Organizational 

processes 

•  Business/mission  need  analysis 

•  System  lifecycle  management 

•  Business  process  reengineering 

•  Quality  assurance 

Table  7.  Cause  of  Variation  Among  Product  Line  Systems 

The  CONOPS  should  define  the  working  relationships  between  asset  and  product  developers. 
For  example: 

Developers  fmm  the  pager  product  group  interact  with  the  ACMYWorks 
architecture  and  component  engineering  groups.  Together  they  define 
operational  requirements  and  deploy  systems  using  ACMYWorks  assets,  as  well 
as  their  own  components.  Developers  may  also  rely  on  the  product  line 
organization  to  provide  domain  expertise  in  key  technology  areas,  such  as 
database,  communications,  and  network  control,  rather  than  maintaining 


34 


CMU/SEI-99-TR-008 


organic  expertise  in  every  area.  Figure  5  illustrates  responsibilities  of  the 
component  development  group  and  the  ACMYWorks  user. 
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Figure  5.  ACMYWorks  Asset  and  Product  Development  Group  Responsibilities 

The  product  line  approach  may  allow  early  demonstration  of  product  line  capabilities  to  a 
candidate  user.  The  CONOPS  should  describe  whether  a  rapid  prototyping  capability  exists 
or  if  existing  products  in  the  product  line  may  fulfill  this  role.  This  early  demonstration 
informs  the  user  of 

•  what  other  products  have  been  built  in  the  product  line  (i.e.,  capabilities,  structure, 
performance  characteristics,  etc.) 

•  the  bounds  of  tailoring 

•  how  requirements  should  be  analyzed  and  how  to  manage  expectations 

•  the  areas  of  risk — ^i.e.,  those  not  currently  covered  by  the  product  line 

Through  such  early  demonstrations,  a  candidate  reuser  will  acquire  the  needed  information  to 
determine  whether  the  product  line  approach  will  be  sufficient  to  meet  all,  or  a  useful  subset, 
of  the  candidate’s  requirements.  The  CONOPS  should  recoimnend  the  following  to  support 
this  phase: 

Action:  Adopt  a  product-line-wide  configuration  management  and  change 
control  policy  for  maintaining  the  product  line’s  core  asset  base. 

Action:  Adopt  a  product-line-wide  measurement  plan  to  assess  quality  and 
measure  ^ectiveness  of  the  product  line  effort. 

Action:  Adopt  a  product-line-wide  set  of  coding  standards. 

Action:  Adopt  a  product-line-wide  testing  standard. 
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Action:  Adopt  a  product-line-wide  performance  engineering  process. 

Action:  Adopt  a  product-line-wide  documentation  standard  for  system  and 
software  requirements,  architecture,  and  reusable  software  components. 

5.1.3  Product  Line  Sustainment  and  Improvement  Phase 

During  the  product  line  engineering  phase,  the  organization  will  apply  management  controls 
for  the  continued  sustainment  and  improvement  of  the  product  line  approach.  The  CONOPS 
should  provide  insight  into  these  controls  and  also  elaborate  upon  the  status  of  the  product 
line.  For  example; 

Once  ACMYWorks  is  fully  developed,  application  engineering  from  ACMYWorks 
will  be  a  normal  part  of  business,  and  management  practices  for  maintaining 
and  improving  the  pager  product  line  will  be  in  place.  Product  line  assets  will 
include  all  reusable  resources  that  support  the  development  of  products  in  the 
pager  product  line. 

The  CONOPS  should  describe  which  assets  are  being  developed  to  support  the  product  line. 
These  will  be  far  more  than  the  software  components  created  during  earlier  phases.  As 
experience  in  use  of  product  line  assets  grows,  the  assets  will  come  to  include  the  following: 


domain  models 

domain  knowledge 

product  line  architectures 

test  plans  and  procedures 

communication  protocol 
descriptions 

requirement  descriptions 

user  interface  descriptions 

configuration  management  plans 
and  tools 

code  components 


performance  nKxlels,  metrics 
work  breakdown  structures 
budgets  and  schedules 
application  generators 
prototypes 

process  components  (methods,  tools) 

COTS  product  profiles 

designs,  design  standards,  design 
decisions 

test  scaffolding 

opportunity  to  refine 


Each  development  cycle  of  a  system  in  the  product  line  will  offer  an 
these  assets. 


For  the  product  line  engineering  phase,  the  CONOPS  should  describe  the  routine  nature  of 
maintenance  of  systems  developed  using  product  line  assets.  The  CONOPS  may  also 
describe  a  product  line  asset  user’s  group  to  facilitate  upgrades.  The  user’s  group  would 
include  representatives  from  products  that  have  used  product  line  assets  in  building  a  system. 
The  CONOPS  should  describe 
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•  common  training  needs  in  asset  development  processes  and  product  development 
processes  that  use  product  line  assets 

•  how  a  user  group  recommends  upgrades  to  the  asset  baseline 

•  sharing  of  experiences  with  other  product  line  asset  users 

The  asset  support  group  will  manage  asset  upgrades  and  changes  to  support  the  user’s  group 
requirements  and  ensure  that  changes  comply  with  product  standards  and  are  within  the 
defined  product  line  scope.  For  this  phase,  the  CONOPS  should  recommend  the  following: 

Action:  Establish  an  enterprise-level  product  line  advisory  group  to  make 
decisions  regarding  product  line  institutionalization. 

Action:  Develop  a  strategic  business  plan  based  on  product  line  measurement 
results. 

Action:  Produce  an  enterprise-level  CONOPS  for  product  line  decision  process. 

5.2  Guidelines  for  Establishing  Organizational  Roles 
and  Responsibilities 

This  section  of  the  CONOPS  address  the  following  key  questions: 

Issue  #8:  What  are  the  key  organizjotional  elements  for  development  of  core 
assets? 

Issue  #9:  What  is  the  relationship  of  core  asset  development  to  product 
development? 


Table  8  summarizes  the  technical  responsibilities  for  four  of  the  key  roles  in  fielding  a 
product  line. 


Element 

Primary  Roles  and  Responsibilities 

Architecture  role 

•  Establishes,  monitors,  and  improves  the  processes  used  in 
the  product  line  approach 

•  Assesses  appropriateness  of  product  line  for  potential 
asset  users 

•  Defines,  maintains,  and  evolves  the  product  line 
architecture 

•  ^th  asset  reusers,  supports  the  evolution  and 
reengineering  of  legacy  systems  for  conformance  to 
product  line  architecture 

•  Defines  standards  and  mediods  for  validating 
conformance  with  architectural  definitions;  responsible  for 
“building  permits’’  and  certifying  conformance 
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Component 
engineering  role 

•  Develops,  procures,  and  evolves  software  (including 

COTS  software)  for  product  lines  and  for  product  line 
assets;  responsible  for  configuration  management 

•  Supplies  domain  expertise  in  key  product  line  technology 
areas 

Product  line  support 
role 

•  Qualifies  environment  products  against  product  line 
architectures 

•  Identifies  enterprise-wide  development  and  execution 
assets  (from  COTS,  government  off-the-shelf  (GOTS), 
and  product  development  groups) 

•  Provides  a  repository  for  test  and  training  use 

Product  group 

•  Integrates  and  delivers  systems 

•  Tailors  the  product  line  architecture  and  components 
through  specialization,  and  custom  development  based  on 
system  requirements 

•  Performs  acceptance  testing  of  delivered  systems 

•  Develops  plans  for  integration  across  product  lines 

•  Manages  deployment  and  installation  of  systems 

Table  8.  Technical  Responsibilities  of  the  Basic  Product  Line  Roles 


Variations  among  product  lines  will  affect  the  responsibilities.  The  results  of  specific 
variations  are  shown  in  Table  9. 


Variation 

Effect 

Product  line  attributes 

The  size  of  typical  systems  or  the  organization  may 
dictate  that  component  and  product  development 
groups  be  merged. 

Asset  procurement  approach 

A  commissioning  organization  will  probably  combine 
many  of  these  responsibilities  into  the  architecture 
group;  the  organization  being  commissioned  will  have 
the  architecture  and  component  groups,  but  possibly 
not  the  product  group. 

Asset  categories 

Decisions  about  which  assets  to  develop  or  to 
emphasize  first  will  affect  the  structure.  There  may  be 
little  component  development  activity  if  the 
architecture  is  the  focus  of  development  for  the  initial 
phase. 

Asset  development  approach 

Asset  development  approach  -  as  above,  the  approach 
to  development  may  emphasize  architecture  over  other 
groups.  In  an  evolutionary  approach,  there  naay  be  few, 
if  any,  component  assets  available  during  the  first 
iteration,  relying  heavily  on  legacy. 

38 


CMU/SEI-99-TR-008 


Use  of  assets  in  application 
engineering 

This  organizational  structure  may  be  too  large  and  its 
responsibilities  too  disbursed  if  the  scope  of 
applicability  of  the  product  is  limited. 

Control  over  assets 

If  assets  are  not  under  direct  control,  responsibilities 
are  more  in  the  nature  of  supplier-consumer. 

Table  9.  Variations  to  Consider  in  Forumulating  the  CONORS 


Based  on  this  set  of  variants,  organizations  may  identify  other  product  line  groups  to  support 
internal  activities.  For  example: 


Element 

Primary  Roles  and  Responsibilities 

ACMYworks  user 

representative 

(marketing) 

•  Defines  and  prioritizes  user  needs  and  clarifies 
requirements 

•  Uses  delivered  systems 

Senior  management 
panel 

•  Establishes  policy  for  product  line  systems  approach;  also, 
policy  for  integrating  across  product  lines  and 
interoperability 

•  Ensures  that  all  programs  are  identified 

•  Approves  identification  of  product  lines 

•  Identifies  and  reserves  funds  for  product  line  creation  and 
development 

•  Approves  each  system  to  be  developed  under  the  product 
line  approach 

ACMYworks 
management  group 

•  Manages  system  development 

•  Serves  as  the  primary  interface  to  users  and  between  other 
product  line  organizations 

•  Supports  product  line  identification 

•  Uses  product  line  definition  to  assist  in  dialog  with  user 
representative  for  deriving  operatiotial  requirements  for 
systems 

•  Analyzes  prototypes 

•  Validates  prototype  results,  where  appropriate 

•  Determines  which,  if  any,  of  the  original  requirements  can 
be  tailored  to  conform  to  product  line  standards 

•  Develops  plans  for  integration  across  product  lines 

Table  10.  Other  ACMYWorks  Product  Line  Groups 
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The  CONORS  should  recommend  the  following: 

Action:  Allocate  personnel  for  the  management  and  functional  areas 
(architecture,  component,  support,  and  product  development)  of  responsibility,  as 
appropriate.  Map  the  areas  onto  existing  organizational  units  (not  necessarily  in 
a  one-to-one  fashion). 

Action:  Adopt  (and  have  reviewed)  a  charter  for  each  functional  area,  outlining 
the  transactional  interface  that  it  has  with  each  of  the  other  three  areas.  Make 
sure  that  the  charter  includes  a  performance  measurement  and/or  assessment 
criteria. 

Action:  Adopt  a  plan  to  ensure  performance  assessment  for  each  area. 

5.3  Guidelines  for  Describing  the  Role  of 
Architecture 

The  CONORS  establishes  architecture  definition  as  critical  to  the  success  of  the  product  line 
approach.  This  section  of  the  CONORS  will  address  the  following: 

Issue  #10:  What  is  the  relationship  between  the  product  line  architecture  and 
systems  within  the  product  line? 

The  product  line  architecture  remains,  throughout  the  life  of  the  product  line,  an  accurate 
conceptual  model  of  the  structure  for  systems  in  the  product  line.  The  CONORS  also 
describes  the  process  by  which  the  product  line  architecture  is  adapted  as  required  for  new 
systeihs.  This  adaptation  is  based  on  information  discovered  during  design  and 
implementation  of  other  systems. 

The  CONORS  should  describe  the  following  activities.  These  occur  within  the  structure 
provided  for  the  product  line  and  the  constraints  imposed  by  the  architects: 

•  how  developers  of  components  for  the  architecture  create  system  components 

•  how  users  of  the  architecture  build  systems 

The  architecture  establishes  an  essential  discipline,  and  compliance  rules  for  designers  and 
implementers.  Key  product  line  decisions  are  made  during  the  process  of  developing  or 
selecting  the  product  line  architecture.  The  CONORS  should  address  decisions  based  on  the 
following  questions/issues: 

•  What  are  the  critical  issues  in  product  line  development  (e.g.,  product  line  selection  and 
inclusion,  understanding/handling  commonalities  and  differences  (i.e.,  domain  model 
issues),  reuse  vision  and  strategy,  security,  interoperability,  and  reliability  in  product 
delivery)? 
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issues),  reuse  vision  and  strategy,  security,  interoperability,  and  reliability  in  product 
delivery)? 

•  What  is  the  relationship  between  the  domain  model  and  the  architecture? 

•  How  will  the  product  line  support  interoperability/conq)onent  integration  issues  (e.g.,  the 
common  object  request  broker  architecture  (CORBA))? 

•  What  are  the  plans  for  compliance  and  levels  of  compliance  within  the  product  line 
architecture? 

•  How  does  the  architecture  reflect  the  overall  reuse  vision  and  strategy? 

•  \^11  legacy  systems  be  supported,  and  how? 

•  How  will  development  support  requirements  be  handled? 

•  What  are  the  plans  for  change/evolution  management  within  the  product  line? 

•  What  is  the  relationship  of  the  product  line  architecture  to  any  mandated  architecture 
standards? 

•  What  are  the  key  quality  factors  (e.g.,  performance,  security,  and  dependability)  that  are 
essential  for  the  success  of  the  product  line? 

•  How  will  the  product  line  take  advantage  of  COTS  or  other  software  sharing? 

The  product  line  architecture  forms  the  basis  for  producing  systems  in  the  product  line.  A 
generative  approach  builds  the  architecture  into  the  automatic  generation  tool.  In  a 
composition  approach,  components  are  integrated  using  the  product  line  architecture.  The 
CONORS  should  describe  and  illustrate  this  process.  For  exanqtle: 

Component  integration  ofACMYWorks  at  the  implementation  stage  occurs  in 
two  steps: 

1.  A  product  line  architecture  is  built  to  provide  a  common  baseline 
architecture  for  all  target  systems  in  the  product  line. 

2.  An  implementation  architecture  for  a  specific  target  system  is  constructed. 

This  produces  the  following  concept  for  building  target  systems  (see  Figure  6): 

1.  The  reference  architecture  provides  the  baseline  for  constructing  a  target 
system.  For  a  specific  pager,  the  components  within  this  architecture  may  be 
tailored  by  modifying  or  adding  to  interfaces. 

2.  The  virtual  machine  layer  is  completed  for  interfacing  to  the  specific 
hardware  configuration  of  the  target  pager  system. 

Pager-unique  applications  are  created  to  complete  the  target  architecture. 
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Resource 

Management 

(common) 


H/W  Interfaces 


Virtual  Machine 
Layer 

Figure  6.  Architectural  Layers  for  Product  Line  Assets 

The  CONOPS  should  recommend  the  following: 

Action:  Agree  on  the  form  and  content  of  a  specification  for  the  product  line 
architecture.  Decide  which  views  of  the  architecture  (process  view,  module  view, 
physical  view,  etc.)  will  be  most  ben^cial.  Decide  what  documentation  should 
be  available  for  the  builder  of  a  system  in  the  product  line  that  uses  the  product 
line  architecture. 

Action:  Adopt  a  component  documentation  plan  that  details  how  a  component 
will  be  documented.  This  should  include  its  interface  specification,  reuser 
information,  documentation  of  algorithms,  etc. 

Action:  Specify  the  product  line  architecture.  Have  it  evaluated. 

Action:  Adopt  a  plan  for  updating  and  evolving  the  architecture  as  the  product 
line  grows  from  its  initial  pilot  state  through  the  sustainment  phase. 

Action:  Design  and  document  a  set  of  architectural  templates  or  tools  that 
automate  the  representation  and  use  of  architectural  templates. 

Action:  Write,  review,  and  plan  for  modifying  the  product  line  developer’s  guide. 


Other  CORBA 
Sen/ices 
(common) 
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5.4  Guidelines  for  Describing  Identification  and 
Maintenance  of  Product  Line  Assets 


This  section  of  the  CONOPS  describes  activities  required  to  identify  and  maintain  product  line 
assets.  It  addresses 

Issue  #11:  What  is  the  source  of  components  and  other  assets? 

These  activities  generally  include  the  following: 

•  identifying,  qualifying,  and  packaging  reusable  resources  (enterprise-wide  assets)  for  use 
in  futiffe  development 

•  making  them  available  for  systems  within  the  product  line  (throu^  a  repository  and 
other  communication  channels) 

•  maintaining  configuration  control  on  versions 

Furthermore,  in  the  case  where  a  product  line  has  made  the  commitment  to  leverage 
commercial  investment  by  focusing  on  the  integration  of  COTS  products  as  a  development 
method,  the  CONOPS  will  set  out  the  steps  necessary  to  have  the  infrastructure  in  place  to 

•  perform  suitability  testing  of  COTS  products  using  a  centrally  maintained  facility 

Under  the  organizational  structure  of  A  Framework  for  Software  Product  Line  Practice, 
[Clements  99]  the  component  engineering  group  is  primarily  responsible  for  performing 
these  tasks.  However,  the  component  group  is  supported  by  the  other  product  line 
organizations.  For  example,  in  identifying  enterprise-wide  assets,  the  architecture  group  will 
play  a  major  role  as  part  of  its  task  in  developing  product  line  architectures.  For  COTS 
products,  the  component  group  will  remain  the  major  source  for  identifying  and  determining 
suitability  of  assets. 

Product  line  variation  will  affect  the  activities  of  asset  identification  and  maintenance. 


Yariatioii 

Effect 

Product  line  attributes  (size,  maturity, 
mission/market  coverage) 

In  a  broadly  scoped  product  line,  this  step  may  be  very 
large.  Assets  may  conoe  from  a  variety  of  sources  and 
must  address  a  wide  range  of  product  line  needs. 

Asset  procurement  approach 

The  organization  shifts  responsibility  for  identification 
and  possibly  maintenance  when  it  commissions  asset 
development.  However,  the  organization  must  exert 
strong  oversight  to  assure  that  assets  meet  expectations. 
Buying  assets  requires  carefril  assessment  and  specific 
selection  criteria. 

Asset  categories  (analysis  models, 
architecture,  components,  others  listed 
in  Section  S.1.3) 

The  tasks  for  identifying  and  maint^ning  assets  vary 
by  asset  category.  The  CONOPS  may  recommend 
individual  approaches  or  assign  these  to  a  developer’s 
guide  or  other  report. 
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Asset  development  approach 
(greenfield,  legacy,  evolutionary) 

Where  legacy  is  the  source  for  assets,  mining  becomes 
a  viable  approach.  Greenfield  asset  development 
generally  requires  a  more  top-down  approach. 
Evolutionary  approaches  may  be  recommended  if  a 
large  number  of  products  must  be  fielded  in  short  order 
with  assets  emerging  and  maturing  with  subsequent 
product  releases. 

Use  of  assets  in  application  engineering 
(complete/partial  system,  frequency  of 
use  in  product  development,  longevity 
of  product  line) 

The  intended  use  of  assets  will  affect  the  emphasis 
placed  on  packaging  or  need  for  a  repository. 

Control  over  assets  (used  internally, 
internal  and  external  use,  made 
available  for  external  use) 

hi-house  vs.  external  development  and  use  play  a 
significant  role  in  asset  identification  and  maintenance. 
An  organization  that  expects  its  assets  to  be  used  by  an 
external  organization  must  invest  heavily  in  packaging 
and  infrastructure  to  support  their  use. 

Table  11.  Effects  of  Variation  on  Identifying  and  Maintaining  Assets 


The  developers  of  the  CONOPS  should  use  these  variants  to  support  the  decision-making 
process  regarding  their  asset  base.  The  next  three  subsections  provide  specific  guidance  for 
describing  the  identifications  of  assets  in  the  CONOPS. 

5.4.1  Enterprise-Wide  Asset  Identification 

The  CONOPS  must  defme  the  product  line  effort  to  identify  reusable  assets  for  the  product 
line  and  to  develop  a  reusable  asset  base.  Asset  development  may  proceed  as  a  new  start, 
proceeding  top-down  from  scoping  and  domain  analysis.  The  CONOPS  will  also  establish 
whether  legacy  systems  must  be  analyzed  to  identify  existing  software  for  possible  use  as 
assets  or  other  reusable  information.  Assets  from  legacy  systems  and  new  development 
include  software,  architectures,  designs,  criteria,  and  other  information.  This  information 
will  be  maintained  in  a  product  line  asset  repository.  Identification  and  packaging  of  these 
enterprise-wide  assets  will  increase  the  asset  base  available  to  all  product  line  asset  reusers. 

Another  ongoing  task  to  support  the  identification  and  distribution  of  enterprise-wide  assets 
is  cross-product  line  analysis.  This  analysis  identifies  opportunities  for  reuse  of  products  and 
knowledge  in  other  product  lines.  The  CONOPS  may  establish  technology  transfer  of  this 
information,  as  well  as  emerging  reuse  techniques  and  methods  across  product  lines,  to 
maximize  the  benefits  of  the  opportunities  identified. 

5.4.2  Repository 

The  product  line  organization  often  maintains  a  repository  of  assets  and  asset  information, 
acquired  through  suitability  testing  and  enterprise-wide  asset  identification  activities.  The 
CONOPS  should  describe  the  structure  of  the  repository,  the  kinds  of  assets  held,  and 
methods  of  organization  according  to  domains  within  the  product  line.  The  CONOPS  should 
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also  define  whether  sensitive  information  will  be  available  through  an  access-controlled 
repository.  A  list  of  the  products  tested  and  the  results  of  suitability  testing  may  be  made 
available  through  a  separately  maintained  product  list.  Eventually,  an  acquisition  mechanism 
for  COTS  products  may  be  provided  in  addition  to  the  product  list. 

The  asset  repository  will  accelerate  and  support  availability  of  proven,  reliable  assets  for 
incorporation  into  product  line  systems.  As  the  repository  is  fully  populated  and  the  working 
relationships  among  the  organizations  mature,  the  CONOPS  may  be  amended  to  define  new 
opportunities  for  reuse. 

5.4.3  Suitability  Testing 

Suitability  testing  is  the  process  of  determining  if  an  off-the-shelf  software  product  meets  the 
architectural  and  functional  requirements  of  a  component  area  within  the  product  line 
software  architecture.  Off  the  shelf  products  include  COTS,  GOTS,  products  of  standards 
organizations,  or  freeware.  The  products  are  tested  using  a  standard  process  for  product  line. 
Where  suitability  testing  is  performed,  the  CONOPS  describes  the  process  and  suitability 
criteria  derived  fi'om  the  architecture  to  provide  an  objective  analysis  of  the  functionality  of 
the  COTS/GOTS.  The  suitability  criteria  are  derived  from  product  line  requirements  and 
architecture  and  wiU  be  developed  and  maintained  as  a  part  of  the  assets.  The  results  of  the 
suitability  testing  of  GOTS  and  COTS  components  will  be  used  in  placing  these  products  in 
the  approved  product  list  for  the  product  line. 

Specific  actions  that  may  be  recommended  within  this  area  include  the  following: 

Action:  Initiate  component  development  activity  within  the  appropriate 
development. 

Action:  Begin  a  reengineering  effort  to  modify  legacy  software,  where 
appropriate,  to  comply  with  the  architecture  and  the  documentation  standards. 

Adopt  a  migration  plan  that  prioritizes  this  work  so  that  the  most  critical 
components  are  completed  first  and  available  for  reuse. 

Action:  Identify  appropriate  off-the-shelf  software  for  use  as  components  within 
the  product  line. 

Action:  Adopt  a  migration  plan  to  add  other  reusable  artifacts  (such  as  budgets 
and  schedules,  test  plans  and  test  cases,  etc.)  to  the  asset  base. 
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5.5  Guidelines  for  Describing  Development  and 
Execution  Environments 


This  section  of  the  CONOPS  addresses  the  following: 

Issue  §12:  What  product  line  support  tools  including  generators  exist  or  will  be 
created? 

The  CONOPS  will  describe  the  environments  provided  for  product  line  support.  These  may 
fall  into  three  areas: 

•  The  development  environment  -  This  includes  the  software  development,  test,  integration, 
and  maintenance  environments,  from  development  through  installation.  The  architecture 
and  component  engineering  groups  use  this  environment  to  develop  product  line  assets; 
the  product  development  groups  use  them  to  produce  products  for  users. 

•  The  execution  environment  -  This  environment  deAnes  hardware/software  integration  on 
the  target  host  for  systems  in  the  product  line.  It  establishes  actual  system  behavior  in 
terms  of  interactions  for  product  line  products.  The  execution  environment  also  supports 
performance  analysis  based  on  the  use  of  specific  combinations  of  component  assets 
within  the  product  line  architecture. 

•  The  support  environment  -  In  some  product  lines,  individual  systems  are  deployed 
throu^  the  support  environment  where  the  user  provides  parameters  to  define  system 
operations,  user  characteristics,  and  system  environments.  The  support  environment 
delivers  an  operational  system  via  con^osition,  generation,  or  a  combination  of  these.  It 
may  support  installation.  Variations  among  systems  in  the  product  line  systems  may 
result  in  differing  support  environments  for  development,  prototyping,  etc. 

The  environments  may  be  separate  products  or  one  environment  may  combine  capabilities. 

For  systems  in  a  product  line,  there  may  be  a  variety  of  potential  host  configurations.  The 
CONOPS  should  describe  the  mechanism  for  defining  a  configuration  and  supporting 
analysis.  This  analysis  for  a  new  system  in  the  product  line  must  include  configurations  of  the 
various  customer  sites  and  interfacing  systems.  There  may  also  be  specific  COTS 
components  or  proprietary  systems  interfacing  with  product  line  systems. 
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5.6  Guidelines  for  Describing  the  Evaluation  Process 
for  Candidate  Asset  Users 


The  CONOPS  should  describe  the  process  for  working  with  potential  product  line  asset  users. 
A  candidate  asset  user  may  request  information  about  the  applicability  of  assets  for  a  new 
system.  The  CONOPS  will  designate  who  will  lead  and  coordinate  an  evaluation  and 
subsequent  interactions  with  this  user.  This  evaluation  determines  if  assets  can  accommodate 
the  candidate  user’s  requirements.  For  example: 

The  evaluation  process  for  candidate  ACMYWorks  users  consists  of  two 
activities:  preliminary  evaluation  and  detailed  evaluation.  The  intent  of  the 
preliminary  evaluation  phase  is  to  take  a  top-level  look  at  the  user’s  technical 
requirements  for  a  new  pager  and  determine  feasibility.  ACMYWorks  historical 
data  from  the  asset  base  allows  accurate  predictions  for  costs  and  development 
schedules  based  on  pager  requirements.  The  aim  of  this  initial  evaluation  is  to 
identify  any  fundamental  incompatibilities  that  would  make  it  impractical  for  use 
of  ACMYWorks  to  meet  the  user’s  needs.  If  the  results  of  the  preliminary 
evaluation  are  favorable,  the  candidate  user  will  conduct  the  detailed  evaluation, 
which  will  establish  the  specie  technical,  cost,  and  schedule  commitments  that 
can  be  supported  by  ACMYWorks  with  regard  to  this  user’s  requirements.  The 
evaluation  and  analysis  processes  for  candidate  ACMYWorks  users  are  outlined 
in  the  “ACMYWorks  Business  Plan:  Sustainment  Phase.  ’’ 

5.7  Guidelines  for  Describing  Product  Line  Asset 
Development  Processes 

This  sections  of  the  CONOPS  addresses  development  processes  to  be  used  for  assets  and  for 
specific  products  in  the  product  line.  The  CONOPS  establishes  processes  for  asset 
development  to  address: 

Issue  #13:  What  will  be  the  process  for  product  line  asset  development  or 
identification? 

These  processes  must  be  defined  for  in-house  development.  Where  asset  development  is 
commissioned,  the  CONOPS  should  recommend  steps  for  working  with  the  developer. 
Individual  products  in  the  product  line  will  use  assets  at  all  levels  of  the  architecture.  For 
example: 

Battl^eld2000  supports  use  of  assets  at  all  levels  of  the  architecture  for  building 
specific  products: 
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•  Infrastructure  assets  -  These  are  the  assets  that  make  up  the  reference  architecture 
and  provide  services  for  component  connection  and  execution. 

•  Shared  component  assets  -Together  with  the  infrastructure,  these  assets  provide  the 
common  application  frameworks  for  all  applications  using  Battl^eldlOOO.  They 
will  satisfy  requirements  for  the  system  target  architectures. 

•  System  specific  assets  -  Individual  battlefield  C2  systems  will  develop  assets  to 
support  mission-unique  requirements  for  that  system.  They  will  be  built  using 
common  infrastructure,  shared  application  assets,  and  system  architecture 
components. 

The  CONOPS  will  provide  brief  scenarios  of  the  processes  for  creating  large-grain 
(subsystem-level)  con:q)onent  assets  and  using  those  assets  to  create  product  line  products. 

5.7.1  Developing  Assets 

A  CONOPS  will  designate  a  specific  product  line  organization  to  perform  asset  development. 
In  A  Framework  for  Software  Product  Line  Practice  [Clements  99],  the  component 
engineering  group  illustrated  in  Figure  2  will  develop  shared  component  assets.  If  the  assets 
will  be  purchased  or  commissioned,  the  CONOPS  describes  this  alternate  process.  Asset 
development  will  be  derived  from  the  general  product  line  description  developed  by  the 
architecture  group.  Assets  may  be  developed  from  scratch  or  may  be  mined  from  legacy 
systems.  Where  assets  are  acquired  off  the  shelf,  the  component  engineering  and  support 
functions  may  be  combined  to  perform  asset  selection.  The  products  of  this  asset 
development  will  include  large-grain  components.  The  process  is  commonly  referred  to  as 
domain  engineering. 

The  CONOPS  may  elaborate  the  steps  in  this  process.  For  example: 

The  component  engineering  group  will  follow  these  practices: 

•  Domain  scoping  -  From  analysis  of  the  product  line  description,  the  developers 
gain  an  understanding  of  the  key  domains  for  Battlefield2000  assets.  These 
domains  are  actually  recognized  areas  of  expertise  within  the  battlefield  C2 
community:  action  planning,  execution,  tracking,  and  others.  The  component 
engineering  group  must  establish  the  connections  and  relationships  between  these 
domains  and  also  scope  their  bounds  of  applicability.  During  this  phase,  the 
component  engineering  group  will  also  determine  which  areas  are  appropriate  for 
common  application  support  and  which  are  mission  specfic. 

•  Domain  modeling  -  Within  each  domain,  the  component  engineering  group 
produces  a  domain  model  to  refine  its  understanding  of  the  domain  and  then 
defines  the  domain-specific  requirements.  This  understanding  will  identify  areas  of 
commonality  across  battlefield  C2  systems  and  those  that  will  differ.  The  domain 
model  will  be  represented  in  the  form  of  object,  feature,  and  behavior  models.  The 
component  group  may  also  build  and  test  prototypes  within  the  domain. 

•  Domain  architecture  -  Each  component  asset  will  be  integrated  into  the  product 
line  architecture  established  by  the  architecture  group.  The  component  engineering 
group  uses  the  product  line  architecture  as  a  basis  for  component  design, 
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partitioning  domain  requirements  to  subsystem  and  object  level  and  dining  the 
connections.  The  component  design  also  defines  details  of  interfaces  to  the 
component  and  connections  to  other  component  assets. 

•  Domain  implementation  -  Component  implementation  develops  detailed  design  of 
the  component  assets.  The  implementation  must  define  mechanisms  for  handling 
variation  of  use  of  the  components.  Variation  techniques  may  include 
parameterization,  inheritance,  or  generation.  These  and  other  implementation 
methods  are  fully  explored  by  Jacobson  [Jacobson  97]. 

The  CONORS  description  is  only  a  summary  of  a  more  extensive  domain  engineering 
process.  The  CONORS  will  refer  to  a  developer’s  guide  or  other  reference  for  the  detailed 
process  description. 

5.7.2  Developing  Product  Line  Products 

The  product  line  architecture  provides  the  basis  for  development  of  a  specific  system  in  the 
product  line.  The  CONORS  will  describe  in  general  terms  the  process  for  creating  a  system. 
The  product  line  organization  should  develop  a  separate  guide  for  details.  The  CONORS 
may  provide  scenarios  for  various  steps  within  the  overall  process. 

The  approach  to  developing  individual  products  varies  widely.  Table  12  summarizes  the 
effects  of  some  of  these  variations: 
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Variation 

Effect 

Product  line  attributes  (size,  maturity, 
mission/market  coverage) 

The  size/complexity  of  the  typical  system  may  dictate 
the  need  for  automated  support.  The  type  of  market  for 
the  product  line  may  affect  the  degree  of  user 
interaction  for  defining  product  requirements. 

Asset  procurement  approach 

The  source  of  assets  may  limit  their  tailorability  for  a 
given  product  development.  Product  groups  must  be 
aware  of  the  types  of  changes  or  enhancement  that  can 
be  made  before  promising  solutions  using  the  existing 
asset  base. 

Asset  categories  (analysis  models, 
architecture,  components,  others  listed 
in  Section  5.1.3) 

Predictability  will  be  influenced  by  the  extent  of  assets 
available  to  support  product  development  and  the 
maturity  of  those  assets.  The  CONOPS  should  be 
careful  to  address  which  areas  of  product  development 
are  fiilly  covered  by  assets  (e.g.,  mature,  in-depth 
components)  and  those  which  are  not  (e.g.,  architecture 
has  identified  components,  but  they  have  not  been  built 
or  are  immature). 

Asset  development  approach 
(greenfield,  legacy,  evolutionary) 

Evolutionary  approaches  incorporate  asset 
development  into  a  series  of  product  deliveries.  Part  of 
the  product  development  activity  includes  asset 
refinement.  Legacy  asset  development  has  some 
similarities  but  may,  like  a  greenfield  product  line,  have 
assets  established  up-front  for  subsequent  product 
delivery.  The  CONOPS  should  point  out  the  process  to 
be  established  and  the  relationship  between 
development  of  products  in  the  product  line. 

Use  of  assets  in  application  engineering 
(complete/partial  system,  frequency  of 
use  in  product  development,  longevity 
of  product  line) 

The  CONOPS  must  point  out  the  coverage  of  assets 
and  where  new  development  is  expected  to  take  place. 

Control  over  assets  (used  internally, 
internal  and  external  use,  made 
available  for  external  use) 

The  CONOPS  should  be  clear  about  the  limitations  of 
assets  purchased  or  available  from  an  external  source. 

It  should  also  describe  the  interface  to  the  controlling 
organization. 

Table  12.  Variations  in  Product  Line  Product  Development 
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6  Developing  the  Recommendations 
Section 


This  section  of  the  CONOPS  recommends  the  order  for  steps  to  be  taken  in  fielding  the 
product  line.  This  approach  may  be  incremental  and  evolutionary  working  from  the 
architecture  and  a  small  group  of  essential  components.  There  are  many  advantages  to  the  use 
of  this  approach.  These  include  the  ease  of  working  from  a  small  core  and  adding 
functionality  progressively,  early  validation  of  system-wide  design  decisions,  promotion  of 
parallel  development,  easier  integration  with  much  greater  robusmess  of  the  system  concepts, 
and  facilitation  of  estimating  system  performance,  quality,  and  cost.  Other  organizations  may 
favor  a  more  top-down  approach,  where  products  are  not  produced  xmtil  the  asset  base  is 
fairly  complete. 

The  CONOPS  should  establish  the  product  line  approach  as  the  basis  for  early 
implementation  and  prototyping.  This  approach  supports  estimation  of  performance  and 
quality  characteristics,  and  the  evolution  of  a  new  product  line  system  from  a  small 
functioning  core  to  the  fiill  system.  After  the  initial  iq)proach  is  established,  the  CONOPS 
should  define  steps  to  expedite  the  following  actions: 

•  )^thin  the  management  organization,  identify  a  champion  and  assure  continuity  of 
leadership  for  implementing  the  concept  of  operations.  The  champion  provides  long-term 
support  for  program  management  through  later  phases. 

•  Assign  responsibilities  for  managing  the  overall  product  line  approach. 

•  Create  product  line  groups  within  the  organization  to  perform  key  roles,  e.g., 
architecture,  component  development  and  product  development.  Some  approaches  may 
provide  for  conq)onent  engineering  out  of  individual  product  development  groups.  These 
groups  are  not  created  for  every  new  product  line,  but  only  when  existing  groups  cannot 
or  should  not  support  a  new  product  line. 

•  Analyze  the  current  product  mix  to  identify  additional  potential  product  lines.  The 
analysis  should  review  the  current  status  of  programs  and  the  plans  for  future  evolution. 
The  organization  must  consider  its  current  and  anticipated  customer  base.  It  is  possible 
that  ongoing  programs  will  need  resources  and/or  relief  in  program  milestones  to  assist  in 
the  development  of  the  asset  base  and  transition  to  product  lines. 

•  Define  the  assets  for  product  line  development  according  to  desired  product  variety  and 
customer  needs.  The  CONOPS  should  identify  the  processes  that  are  part  of  asset 
creation  including  domain  engineering,  architecture  description  and  assessment,  and 
reengineering  to  deal  with  legacy  systems.  The  architecture  group  will  generally  be 
responsible  for  defining  and  monitoring  these  processes.  The  CONOPS  may  designate 
an  alternate. 
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•  Promote  the  continued  evolution  of  the  product  line.  This  includes  interacting  with  other 
related  systems  and  providing  incentives  for  asset  improvement  to  enhance  future 
product  releases  in  the  areas  of 


•  performance  improvements 

•  bridges  to  other  systems 

•  auxiliary  tools  to  facilitate  the 
customization  of  components 

•  documentation  improvements 


•  component  management  and 
change  management  facilities 

•  platform  extensions  for 
improved  portability 

•  improvements  of  techniques 
for  legacy  system  migration 

•  evolutionary  change  to  keep 
pace  with  new  technologies 


The  CONOPS  can  define  a  transition  path  for  promoting  the  use  of  assets  in  legacy  systems. 
This  should  include  an  active  search  for  ongoing  projects  that  can  immediately  contribute  to 
the  product  line  approach.  The  CONOPS  should  propose  methods  to  enhance  the  product 
line  by  working  with  these  projects  to  make  sure  they  are  aware  of  product  line  assets,  or  to 
identify  components  they  are  producing  that  can  become  product  line  assets. 
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7  Summary 


As  part  of  the  decision  to  go  to  a  product  line  approach,  the  organization’s  business  analysis 
will  establish  product  line  goals,  objectives,  and  strategies.  These  guidelines  should  lead  to  a 
CONOPS  that  establishes  an  approach  for  achieving  the  goals.  The  guidelines  also  offer 
recommendations  for  developing  the  product  line  approach  for  a  specific  organization  or 
context.  They  also  recommend  where  and  how  to  apply  the  product  line  approach. 

The  CONOPS  describes  the  roles  and  responsibilities  of  groups  involved  in  creating  the 
product  line.  Where  development  is  performed  in  house,  the  CONOPS  will  identify  which 
groups  have  architecture  or  component  responsibilities  and  whether  these  are  separate  groups 
or  connected  to  specific  products.  For  government  or  other  commissioning  organizations,  the 
CONOPS  will  define  acquisition/supplier  interactions  to  develop  a  common  architecture  and 
other  assets.  While  it  is  not  necessary  for  the  acquiring  oiganization  to  own  all  the  assets  in 
the  product  line  asset  base,  the  CONOPS  and  the  decisions  it  embodies  must  define 
appropriate  access  to  them.  The  acquisition  and  ownership  policy  for  product  line 
architectures  is  currently  under  investigation  by  several  groups  within  the  DoD  [Addy  98]. 

Product  line  development  evolves  naturally  from  applying  fundamental  engineering  concepts 
to  meeting  recurring  needs.  Recurring  requirements  provide  the  potential  for  economies  of 
scale  and  reuse.  The  CONOPS  should  support  the  goal  of  doing  the  job  better,  faster,  and 
cheaper,  by  focusing  on  efforts  that  reduce  the  costs  and  risks  associated  with  system 
development. 
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Appendix  A  Key  CONORS  Questions 


Key  Question 

CONORS  Guideline  Examples 

1 .  What  is  the  product  line?  What  mission  or 
application  area  will  be  satisfied  by 
systems  in  the  product  line? 

ACMYworks  for  pager  products 

Battlefield2000  for  battlefield  command  and 
control  systems 

2.  How  will  product  line  assets  and  product 
line  products  be  developed  or  acquired?  Is 
there  an  acquisition/supplier  relationship? 

Developed  in  house 

Commissioned 

Hybrid 

3 .  Who  is/will  be  the  product  line  champion? 

Battlefield2000  program  manager 

4.  What  is  the  relationship  between  the 
product  line  and  product  line  assets, 
especially  the  architecture? 

Architecture-based  development;  use  of 
components  and  composition  tools 

Alternatively,  generator  technology  for 
producing  members  of  the  product  line 

5.  How  will  the  product  line  be  introduced? 

Three  phases  (domain  engineering,  application 
engineering,  product  line  engineering) 

Alternatively,  expand  the  coverage  to  include 
new  domains  within  the  product  line 

6.  What  is  the  strategy  beyond  this  product 
line? 

Identify  new  users,  deepen  coverage  within  the 
product  line 

Alternatively,  identify  new  product  lines 

7.  Who  are  the  users  of  product  line  assets? 

Product  line  asset  reusers,  product  development 
groups 

8.  What  are  the  key  organizational  elements 
within  domain  engineering? 

Architecture  group,  component  engineering 
group,  product  line  support  group 

9.  What  is  the  relationship  of  the  domain 
engineering  organization  to  application 
engineering? 

Separate  management  structures 

Alternatively,  domain  engineering  is  derived 
from  an  application  engineering  effort 

10.  What  is  the  relationship  between  the 

product  line  and  systems  within  the  product 
line? 

Product  line  assets  are  used  to  construct  a 
specific  system 

Alternatively,  one  or  more  levels  of  interaction 
between  assets  and  the  system 

1 1.  What  is  the  source  of  components  and 
other  assets? 

Mining  firom  legacy 

Alternatively,  COTS 
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12.  What  product  line  support  tools  including 
generators  exist  or  will  be  created? 

Tools  supporting  architecture  representation, 
asset  development,  composition,  execution 
support 

Alternatively,  generator  tools 

13.  What  will  be  the  process  for  product  line 
asset  development  or  identification? 

Domain  engineering 

58 


CMU/SEI-99-TR-008 


REPORT  DOCUMENTATION  PAGE  SSto^-oio. 

Mtecllon  of  infonnation,  Induding  suggoslkxn  tor  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  tor Jnl^atim  l^ratims  andRe^s,  1215  Jefferson  Davis 
Highway,  Suite  1204,  AHingtnn,  VA  oopng^aang.  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-01 SB),  Washington,  DC  20503. - 

1.  AGENCY  USE  ONLY  (LEAVE  BLANK)  2.  HEPOBTOATE  3.  REPORT  TYPE  AND  DATES 

A  unnn  COVERED 

August  1999 

Final  _ 


4.  TITLE  AND  SUBTITLE 

Guidelines  for  Developing  a  Product  Line  Concept  of  Operations 


6.  AUTHOR(S) 

Sholom  Cohen 


FUNDING  NUMBERS 

C  —  FI  9628-95-C-0003 


8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

CMU/SEI-99-TR-008 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

ESC-TR-99-008 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


9.  SPONSORING/MOMTORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

HQ  ESC/DIB 
5  Eglin  Street 

Hanscom  AFB.  MA  01731-2116  _ 


11.  SUPPLEMENTARY  NOTES 


12. A  DISTHIBUnON/AVAILABILITY  STATEMENT  12.B  DISTRIBUTION  CODE 

Unclassified/Unlimited.  DTIC.  NTIS _ _ _ 

13.  ABSTRACT  (MAXIMUM  200  WORDS) 

This  report  provides  guidelines  for  an  organization  that  is  developing  a  Concept  of  Operations  (CONOPS) 
document.  A  CONOPS  document  defines  the  organization’s  product  line  approach.  The  CONOPS  document 
and  the  decisions  made  in  its  preparation  will  guide  the  organization  as  It  plans  and  executes  the  process  of 
fielding  a  product  line,  from  product  line  scoping,  through  architecture,  component  development,  and  product 
development. 


14.  SUBJECTTERMS 

concept  of  operations  (CONOPS),  product  lines,  product  line  operations. 

15.  NUMBER  OF  PAGES 

57  pp. 

16.  Price  Code 

17.  SECURITY 

CLASSIFICATION 

OF  REFORT 

UNCLASSIFIED 

1 8.  SECURITY  CLASSIFICATION 

OF  THIS  PAGE 

UNCLASSIFIED 

1 9.  SECURITY  CLASSIFICATION 

OF  ABSTRACT 

UNCLASSIFIED 

20.  UMITATION  OF  ABSTRACT 

UL 

NSN  754(H)1-280>5500 

Standard  Form  298  (Rev.  2*89} 

PrMCftMd  fay  ANSI  SId.  Z39-18 

